From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 07:30:37 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03635 for ; Thu, 2 Jan 2003 07:30:36 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02CDbhm016329; Thu, 2 Jan 2003 12:32:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02CAKua016015; Thu, 2 Jan 2003 12:10:20 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 12:10:20 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02CAGhC015997 for ; Thu, 2 Jan 2003 12:10:17 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18U4Av-0007Zo-00; Thu, 2 Jan 2003 13:10:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18U4Av-0002NH-00; Thu, 2 Jan 2003 13:10:13 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: objectIdentifierMatch on ambiguous name Date: Thu, 2 Jan 2003 13:10:13 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: What does filter component (oid=foo) applied to attribute oid=bar evaluate to if the schema defines the following? object class ( ... NAME 'foo' ... ) object class ( ... NAME 'bar' ... ) attribute type ( ... NAME ('foo' 'bar') ... ) attribute type ( ... NAME 'oid' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 08:44:52 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04542 for ; Thu, 2 Jan 2003 08:44:51 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02DkjhK028371; Thu, 2 Jan 2003 13:46:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02Dfw9T027900; Thu, 2 Jan 2003 13:41:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 13:41:58 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02DfrhC027880 for ; Thu, 2 Jan 2003 13:41:54 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18U5bX-00008k-00; Thu, 2 Jan 2003 14:41:47 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18U5bX-0004Zy-00; Thu, 2 Jan 2003 14:41:47 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John McMeeking Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 2 Jan 2003 14:41:47 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit John McMeeking writes: > Given what you presented, the filter doesn't match anything -- yet. > You need some entries with an oid attribute: That's what I meant with "applied to attribute oid=bar". I.e. a search on this entry: dn: cn=some entry oid: bar ... > objectIdentifierMatch has nothing to do with OIDs (or names) defined in a > schema. Huh? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 09:39:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04541 for ; Thu, 2 Jan 2003 08:44:51 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02DkjhM028371; Thu, 2 Jan 2003 13:46:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02Dcpdm027629; Thu, 2 Jan 2003 13:38:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 13:38:51 +0000 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02DclhC027577 for ; Thu, 2 Jan 2003 13:38:47 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02DcM70101862; Thu, 2 Jan 2003 08:38:22 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02DcLh3163214; Thu, 2 Jan 2003 08:38:21 -0500 Subject: Re: objectIdentifierMatch on ambiguous name To: Hallvard B Furuseth Cc: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Thu, 2 Jan 2003 07:38:20 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0|September 26, 2002) at 01/02/2003 07:38:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Given what you presented, the filter doesn't match anything -- yet. You need some entries with an oid attribute: dn: cn=some entry oid: 1.2.3.4 dn: cn=some other entry oid: foo objectIdentifierMatch has nothing to do with OIDs (or names) defined in a schema. Did you have something else in mind? John McMeeking Hallvard B Furuseth cc: Sent by: Subject: objectIdentifierMatch on ambiguous name owner-ietf-ldapbis@O penLDAP.org 01/02/2003 06:10 AM What does filter component (oid=foo) applied to attribute oid=bar evaluate to if the schema defines the following? object class ( ... NAME 'foo' ... ) object class ( ... NAME 'bar' ... ) attribute type ( ... NAME ('foo' 'bar') ... ) attribute type ( ... NAME 'oid' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 10:21:34 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06358 for ; Thu, 2 Jan 2003 10:21:33 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02FGehE039349; Thu, 2 Jan 2003 15:20:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02FAu1t038665; Thu, 2 Jan 2003 15:10:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 15:10:56 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02F7ihC038248 for ; Thu, 2 Jan 2003 15:07:45 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18U6wf-0007Ol-00 for ietf-ldapbis@openldap.org; Thu, 2 Jan 2003 16:07:41 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18U6vc-0006HR-00; Thu, 2 Jan 2003 16:06:36 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: steven.legg@adacel.com.au Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: caseIgnoreListSubstringsMatch is undefined In-Reply-To: <001801c295d2$cfbe9640$a518200a@osmium.mtwav.adacel.com.au> References: <001801c295d2$cfbe9640$a518200a@osmium.mtwav.adacel.com.au> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 2 Jan 2003 16:06:36 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steven Legg writes: >Hallvard B Furuseth wrote: >> draft-ietf-ldapbis-user-schema-03.txt says: >> >>> 3.23 postalAddress >>> (...) >>> SUBSTR caseIgnoreListSubstringsMatch >> >> However, caseIgnoreListSubstringsMatch [X.520(1993) 6.1.11] is not >> defined or referred to in the Syntaxes draft. > > It's being added to the syntaxes draft for the -04 revision. No, it wasn't. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 10:44:45 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06756 for ; Thu, 2 Jan 2003 10:44:44 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02FkqhE042703; Thu, 2 Jan 2003 15:47:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02FYA9B041453; Thu, 2 Jan 2003 15:34:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 15:34:10 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02FY6hC041435 for ; Thu, 2 Jan 2003 15:34:07 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18U7MB-0001pT-00; Thu, 2 Jan 2003 16:34:03 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18U7MB-0006LH-00; Thu, 2 Jan 2003 16:34:03 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: bind no longer abandons outstanding operations Date: Thu, 2 Jan 2003 16:34:03 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: draft-ietf-ldapbis-protocol-12.txt says: > 4.2.1. Processing of the Bind Request > Upon receipt of a BindRequest, the server MUST ensure there > are no outstanding operations in progress on the connection > (This simplifies server implementation). I think it should add It can abandon these operations and/or wait for them to complete and maybe but [need/should] in any case not send any responses to them. Otherwise the text implies that the server must wait for outstanding operations to finish before it can proceed. Previous drafts, and RFC2251, said outstanding operations should be abandoned. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 11:14:41 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07550 for ; Thu, 2 Jan 2003 11:14:40 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02GGchE046212; Thu, 2 Jan 2003 16:16:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02G5BXg044870; Thu, 2 Jan 2003 16:05:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 16:05:11 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02G50hC044726; Thu, 2 Jan 2003 16:05:00 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18U7q3-0003yS-00; Thu, 2 Jan 2003 17:04:55 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18U7q3-0006Po-00; Thu, 2 Jan 2003 17:04:55 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: I-D ACTION:draft-zeilenga-ldapbis-rfc2253-02.txt In-Reply-To: <5.2.0.9.0.20021218094710.02554148@127.0.0.1> References: <200212181302.IAA04230@ietf.org> <5.2.0.9.0.20021218094710.02554148@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 2 Jan 2003 17:04:55 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit 2.3 (Converting AttributeTypeAndValue) says: If the AttributeType has a registered short name [REGISTRY], that registered short name, a , is used. I think the short name "SHOULD" be used, and MUST be used only if it is in the table in 2.3 in RFC2253. That retains compatibiblity with implementations that followed RFC2253 and used the dotted-decimal form for other attribute types. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 11:24:46 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07702 for ; Thu, 2 Jan 2003 11:24:46 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02GQbhE047388; Thu, 2 Jan 2003 16:26:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02GF72A046068; Thu, 2 Jan 2003 16:15:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 16:15:07 +0000 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02GF2hC045990 for ; Thu, 2 Jan 2003 16:15:03 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02GEf5Y120498; Thu, 2 Jan 2003 11:14:41 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02GEdh3017274; Thu, 2 Jan 2003 11:14:40 -0500 Subject: Re: objectIdentifierMatch on ambiguous name To: Hallvard B Furuseth Cc: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Thu, 2 Jan 2003 10:14:39 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0|September 26, 2002) at 01/02/2003 10:14:41 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Beats me -- now that my brain is functioning a little better. And I ought to get this thread back to the mailing list. An obvious instance of this type of filter is (objectclass=person). And it is fairly clear what a client would expect to the server to do in that case: (objectclass=person) and (objectclass=2.5.6.6) ought to be equivalent. The existence of an attributetype also named person (discouraged, but legal) should not affect this filter. Two objectclasses with the same name (within a given subschema) would be a problem, but I'd be suprised if a server allowed it. For any other attribute with objectIdentifierMatch, I, as a user, would be suprised if the server did any to conversion. Reading the specs, I would expect a server to allow me to create an entry with values like 1.2.3.4 or foo, and do something like a case insensitive match (FOO = foo) but I wouldn't expect "foo" to match a numeric oid. Given that OIDs can be used for anything, it seems unreasonable to expect that there would be a one-to-one to mapping outside of a given application realm. At best, any to mapping would be depend on the attribute being used and would either be server defined, or be defined by some other standard. For example, a standard could define names for widget types, where each widget type also has a registered OID. Then, maybe, it would make sense to expect (widgetType=foo) to match widgetType=6.6.6; but it wouldn't make sense to expect (myOidAttr=foo) to match the value myOidAttr=6.6.6. Maybe [SYNTAXES] should try to clarify this. Or maybe [SYNTAXES] should remove reference to values assertions using form of OIDs in the spirit of "liberal in what you accept, strict in what you send." John McMeeking Hallvard B Furuseth To: John McMeeking/Rochester/IBM@IBMUS Subject: Re: objectIdentifierMatch on ambiguous name 01/02/2003 08:43 AM John McMeeking writes: > Going back to your example: > > object class ( ... NAME 'foo' ... ) > object class ( ... NAME 'bar' ... ) > attribute type ( ... NAME ('foo' 'bar') ... ) > > the filter (oid=foo) has nothing to do with these. It only matches entries > that have an "oid" attribute with the value "foo". I don't think so. [Syntaxes] 5.2.17 (objectIdentifierMatch) says: The rule evaluates to TRUE if and only if the assertion value and the attribute value represent the same object identifier, that is, the ^^^^^^^^^ ^^^ same sequence of integers, whether represented explicitly in the ^^^^^^^^^^^^^^^^^^^^^^^^^ form of or implicitly in the form (see [MODELS]). So as far as I can tell, objectIdentifierMatch should convert the name 'foo' to a sequence of integers and then try to match. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 12:04:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08633 for ; Thu, 2 Jan 2003 12:04:33 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02H6ghE048579; Thu, 2 Jan 2003 17:06:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02GtlJ6048298; Thu, 2 Jan 2003 16:55:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 16:55:47 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02GthhC048288 for ; Thu, 2 Jan 2003 16:55:43 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h02GtR0a097888; Thu, 2 Jan 2003 16:55:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Jan 2003 08:55:16 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 04:10 AM 1/2/2003, Hallvard B Furuseth wrote: >What does filter component (oid=foo) applied to attribute oid=bar >evaluate to if the schema defines the following? > object class ( ... NAME 'foo' ... ) > object class ( ... NAME 'bar' ... ) > attribute type ( ... NAME ('foo' 'bar') ... ) It likely needs to be clarified that the meaning of 'foo' and 'bar' are context sensitive and MUST NOT be used where the context is not provided. > attribute type ( ... NAME 'oid' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID If this attribute is intended to hold OIDs referring to any kind of object, then short names cannot be used with it. That is, the assertion (oid=foo) is Undefined. I note that if the attribute is intended to hold OIDs referring to a specific kind of object (e.g., attribute types, object classes, matching rules), the server needs also to be aware of this intent in order to map "foo" to the appropriate (numeric) OID. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 2 13:25:12 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10723 for ; Thu, 2 Jan 2003 13:25:11 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02IQnhE050548; Thu, 2 Jan 2003 18:27:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h02IGXro050257; Thu, 2 Jan 2003 18:16:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 2 Jan 2003 18:16:33 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h02IGGhC050246 for ; Thu, 2 Jan 2003 18:16:16 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h02IG00a098169; Thu, 2 Jan 2003 18:16:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030102082345.01d16830@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Jan 2003 10:15:47 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-zeilenga-ldapbis-rfc2253-02.txt Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20021218094710.02554148@127.0.0.1> <200212181302.IAA04230@ietf.org> <5.2.0.9.0.20021218094710.02554148@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:04 AM 1/2/2003, Hallvard B Furuseth wrote: >2.3 (Converting AttributeTypeAndValue) says: > > If the AttributeType has a registered short name [REGISTRY], that > registered short name, a , is used. > >I think the short name "SHOULD" be used, It is. Section 2: "This section defines the RECOMMENDED algorithm..." >and MUST be used only if it is in the table in 2.3 in RFC2253. Section 3 mandates that implementations recognize names in the table. Is there a need to mandate their use? Considering that some implementations took the table as being "an example" and as DC is not in [4], there actually be implementations generating "0.9.2342.19200300.100.1.25=foo,0.9.2342.19200300.100.1.25=com" (or the equivalent using the #ber-hex notation). Are these implementations to be outlawed? >That retains compatibiblity with >implementations that followed RFC2253 and used the dotted-decimal >form for other attribute types. I think we need to continue to allow use of numericoid instead of descr. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 07:05:36 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07769 for ; Fri, 3 Jan 2003 07:05:36 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03C6uhG080386; Fri, 3 Jan 2003 12:07:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03BmBsa079624; Fri, 3 Jan 2003 11:48:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 11:48:11 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03Bm3hC079596; Fri, 3 Jan 2003 11:48:04 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18UQIy-0002I4-00; Fri, 3 Jan 2003 12:48:00 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18UQIx-0001NO-00; Fri, 3 Jan 2003 12:47:59 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: I-D ACTION:draft-zeilenga-ldapbis-rfc2253-02.txt In-Reply-To: <5.2.0.9.0.20030102082345.01d16830@127.0.0.1> References: <5.2.0.9.0.20021218094710.02554148@127.0.0.1> <200212181302.IAA04230@ietf.org> <5.2.0.9.0.20030102082345.01d16830@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 3 Jan 2003 12:47:59 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >>I think the short name "SHOULD" be used, > > It is. Section 2: "This section defines the RECOMMENDED algorithm..." Oh, good. >> and MUST be used only if it is in the table in 2.3 in RFC2253. > > Section 3 mandates that implementations recognize names in > the table. Is there a need to mandate their use? No. I wrote that because thought there was an implicit MUST already, and wanted to restrict it a little. > Considering that some implementations took the table as being > "an example" and as DC is not in [4], there actually be implementations > generating "0.9.2342.19200300.100.1.25=foo,0.9.2342.19200300.100.1.25=com" > (or the equivalent using the #ber-hex notation). Are these > implementations to be outlawed? No. Never mind, it's fine as it is. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 08:12:22 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08534 for ; Fri, 3 Jan 2003 08:12:21 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03DDThG084520; Fri, 3 Jan 2003 13:14:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03D7ed0084454; Fri, 3 Jan 2003 13:07:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 13:07:40 +0000 Received: from galois.openldap.org (kurt@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03D7ahC084443 for ; Fri, 3 Jan 2003 13:07:36 GMT (envelope-from kurt@galois.openldap.org) Received: (from kurt@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) id h03D7ZQ0084442 for ietf-ldapbis@openldap.org; Fri, 3 Jan 2003 13:07:35 GMT (envelope-from kurt) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0398XhC074531 for ; Fri, 3 Jan 2003 09:08:34 GMT (envelope-from helmut.volpers@siemens.com) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h0398VP28158; Fri, 3 Jan 2003 10:08:32 +0100 (MET) Received: from pappel.asw.mchp.siemens.de ([139.25.160.30]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h0398UV09840; Fri, 3 Jan 2003 10:08:30 +0100 (MET) Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jan 2003 10:08:29 +0100 Message-ID: From: "Volpers, Helmut" To: "'John McMeeking'" , Hallvard B Furuseth Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: objectIdentifierMatch on ambiguous name Date: Fri, 3 Jan 2003 10:08:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I agree with John. I think the most Servers allow objectIdentifierMatch only on attributes with OID syntax (not on a String syntax). Objectclass is a special Attribute where the most Servers support OID matching as well as String matching, but for all other attributes with an OID syntax it is okay if the Server supports objectIdentifierMatch. Regards Helmut > -----Original Message----- > From: John McMeeking [mailto:jmcmeek@us.ibm.com] > Sent: Donnerstag, 2. Januar 2003 17:15 > To: Hallvard B Furuseth > Cc: ietf-ldapbis@OpenLDAP.org > Subject: Re: objectIdentifierMatch on ambiguous name > > > > > > > > > > > Beats me -- now that my brain is functioning a little better. > And I ought > to get this thread back to the mailing list. > > An obvious instance of this type of filter is > (objectclass=person). And it > is fairly clear what a client would expect to the server to do in that > case: (objectclass=person) and (objectclass=2.5.6.6) ought to be > equivalent. The existence of an attributetype also named person > (discouraged, but legal) should not affect this filter. Two > objectclasses > with the same name (within a given subschema) would be a > problem, but I'd > be suprised if a server allowed it. > > For any other attribute with objectIdentifierMatch, I, as a > user, would be > suprised if the server did any to > conversion. Reading > the specs, I would expect a server to allow me to create an entry with > values like 1.2.3.4 or foo, and do something like a case > insensitive match > (FOO = foo) but I wouldn't expect "foo" to match a numeric > oid. Given that > OIDs can be used for anything, it seems unreasonable to > expect that there > would be a one-to-one to mapping outside > of a given > application realm. > > At best, any to mapping would be depend on the > attribute being used and would either be server defined, or > be defined by > some other standard. For example, a standard could define > names for widget > types, where each widget type also has a registered OID. > Then, maybe, it > would make sense to expect (widgetType=foo) to match > widgetType=6.6.6; but > it wouldn't make sense to expect (myOidAttr=foo) to match the value > myOidAttr=6.6.6. > > Maybe [SYNTAXES] should try to clarify this. Or maybe > [SYNTAXES] should > remove reference to values assertions using form of > OIDs in the > spirit of "liberal in what you accept, strict in what you send." > > > John McMeeking > > > > > > Hallvard B > > Furuseth To: John > McMeeking/Rochester/IBM@IBMUS > > t.uio.no> Subject: Re: > objectIdentifierMatch on ambiguous name > > > 01/02/2003 08:43 > > AM > > > > > > > > > > John McMeeking writes: > > Going back to your example: > > > > object class ( ... NAME 'foo' ... ) > > object class ( ... NAME 'bar' ... ) > > attribute type ( ... NAME ('foo' 'bar') ... ) > > > > the filter (oid=foo) has nothing to do with these. It only matches > entries > > that have an "oid" attribute with the value "foo". > > I don't think so. [Syntaxes] 5.2.17 (objectIdentifierMatch) says: > > The rule evaluates to TRUE if and only if the assertion > value and the > attribute value represent the same object identifier, that is, the > ^^^^^^^^^ ^^^ > same sequence of integers, whether represented explicitly in the > ^^^^^^^^^^^^^^^^^^^^^^^^^ > form of or implicitly in the form (see > [MODELS]). > > So as far as I can tell, objectIdentifierMatch should convert the name > 'foo' to a sequence of integers and then try to match. > > -- > Hallvard > > > From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 09:22:15 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09741 for ; Fri, 3 Jan 2003 09:22:14 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03EE1hU086145; Fri, 3 Jan 2003 14:24:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03DvIOl085750; Fri, 3 Jan 2003 13:57:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 13:57:18 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03DvEhC085738 for ; Fri, 3 Jan 2003 13:57:15 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18USJt-000172-00; Fri, 3 Jan 2003 14:57:05 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18USJp-0001fx-00; Fri, 3 Jan 2003 14:57:01 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Volpers, Helmut" Cc: John McMeeking , ietf-ldapbis@OpenLDAP.org Subject: RE: objectIdentifierMatch on ambiguous name In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 3 Jan 2003 14:57:01 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Volpers, Helmut writes: > I think the most Servers allow objectIdentifierMatch only on > attributes with OID syntax (not on a String syntax). That's what my example does too. I'm not talking about applying objectIdentifierMatch to an attribute with string syntax. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 09:22:23 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09756 for ; Fri, 3 Jan 2003 09:22:22 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03EE1hS086145; Fri, 3 Jan 2003 14:24:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03DtOv2085649; Fri, 3 Jan 2003 13:55:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 13:55:24 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03DtHhC085620; Fri, 3 Jan 2003 13:55:17 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18USI5-0000uD-00; Fri, 3 Jan 2003 14:55:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18USI5-0001er-00; Fri, 3 Jan 2003 14:55:13 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> References: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 3 Jan 2003 14:55:13 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >> attribute type ( ... NAME 'oid' >> EQUALITY objectIdentifierMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID > > If this attribute is intended to hold OIDs referring to any > kind of object, then short names cannot be used with it. That > is, the assertion (oid=foo) is Undefined. > > I note that if the attribute is intended to hold OIDs referring > to a specific kind of object (e.g., attribute types, object > classes, matching rules), the server needs also to be aware of > this intent in order to map "foo" to the appropriate (numeric) > OID. That seems a bit strict to me. I think the filter (oid=foo) should match an oid attribute with value "foo", at least. Otherwise, if the admin wants to define an attribute which holds the names (descriptors) of attribute names, and the server doesn't provide an extension which lets him tell it which OID namespace the attribute uses, he must use Printable String syntax and caseIgnoreMatch instead of OID syntax and objectIdentifierMatch. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 10:59:35 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11837 for ; Fri, 3 Jan 2003 10:59:35 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03FhThu090112; Fri, 3 Jan 2003 16:01:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03FYOP5089480; Fri, 3 Jan 2003 15:34:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 15:34:24 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03FY4hC089439 for ; Fri, 3 Jan 2003 15:34:04 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h03FXl0a003130; Fri, 3 Jan 2003 15:33:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 03 Jan 2003 07:33:35 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 05:55 AM 1/3/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> attribute type ( ... NAME 'oid' >>> EQUALITY objectIdentifierMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID >> >> If this attribute is intended to hold OIDs referring to any >> kind of object, then short names cannot be used with it. That >> is, the assertion (oid=foo) is Undefined. >> >> I note that if the attribute is intended to hold OIDs referring >> to a specific kind of object (e.g., attribute types, object >> classes, matching rules), the server needs also to be aware of >> this intent in order to map "foo" to the appropriate (numeric) >> OID. > >That seems a bit strict to me. I think the filter (oid=foo) >should match an oid attribute with value "foo", at least. I don't think "foo" should be allowed as a value of 'oid'. Because allowing "foo" allows "bar" and that requires there to be a way for the server to determine whether "foo" and "bar" are equal or not. However, the implementation has no knowledge of which mapping table, or which subset of a table, of short names to numeric oids applies; the question of whether "foo" is equal to "bar" is, without context, Undefined. Nor could "foo" and 1.2.3 be added to "oid" without whether "foo" and 1.2.3 are equal. The assertion (oid=1.2.3) is likewise Undefined if "oid" contains the value "foo". >Otherwise, if the admin wants to define an attribute which holds >the names (descriptors) of attribute names, and the server doesn't >provide an extension which lets him tell it which OID namespace >the attribute uses, he must use Printable String syntax and >caseIgnoreMatch instead of OID syntax and objectIdentifierMatch. Yes. That's exactly what the admin should do if he wants to hold NAMEs. Names in X.500 and, generally in LDAP, are just printable stings which have no meaning except in a few limited contexts. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 14:53:53 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17715 for ; Fri, 3 Jan 2003 14:53:53 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03JhThG011483; Fri, 3 Jan 2003 19:56:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03JgLMO011266; Fri, 3 Jan 2003 19:42:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 19:42:21 +0000 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03JgEhC011036; Fri, 3 Jan 2003 19:42:14 GMT (envelope-from Mark.Wahl@sun.com) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17307; Fri, 3 Jan 2003 12:42:13 -0700 (MST) Received: from sun.com (dhcp-uaus09-130-208 [129.153.130.208]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03JgC405475; Fri, 3 Jan 2003 13:42:13 -0600 (CST) Message-ID: <3E15E807.AD063853@sun.com> Date: Fri, 03 Jan 2003 13:44:07 -0600 From: Mark Wahl X-Mailer: Mozilla 4.79 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Hallvard B Furuseth CC: "Kurt D. Zeilenga" , ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name References: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > If this attribute is intended to hold OIDs referring to any > > kind of object, then short names cannot be used with it. That > > is, the assertion (oid=foo) is Undefined. > > > > I note that if the attribute is intended to hold OIDs referring > > to a specific kind of object (e.g., attribute types, object > > classes, matching rules), the server needs also to be aware of > > this intent in order to map "foo" to the appropriate (numeric) > > OID. > > That seems a bit strict to me. I think the filter (oid=foo) > should match an oid attribute with value "foo", at least. I'd tend to side with Kurt on this one though. The 'at least' part is worrying. I'd prefer to say that the server MUST support matching with a numericoid assertion value. Perhaps it could be a server feature to have OID matching with short names. > Otherwise, if the admin wants to define an attribute which holds > the names (descriptors) of attribute names, and the server doesn't > provide an extension which lets him tell it which OID namespace > the attribute uses, he must use Printable String syntax and > caseIgnoreMatch instead of OID syntax and objectIdentifierMatch. Or the admin could use an extensible matching rule with the OID syntax. A similar issue is the objectIdentifierFirstComponentMatch MR for the attributes attributeTypes and objectClasses. Should only numericoid be permitted in the search filter assertion value? If not, then it runs into the same difficulty as here. Mark Wahl Sun Microsystems Inc. From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 14:54:59 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17737 for ; Fri, 3 Jan 2003 14:54:58 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03JrThK015039; Fri, 3 Jan 2003 19:57:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03Jll92012977; Fri, 3 Jan 2003 19:47:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 19:47:46 +0000 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03JldhC012508; Fri, 3 Jan 2003 19:47:39 GMT (envelope-from Mark.Wahl@sun.com) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21777; Fri, 3 Jan 2003 11:47:18 -0800 (PST) Received: from sun.com (dhcp-uaus09-130-208 [129.153.130.208]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h03JlI405648; Fri, 3 Jan 2003 13:47:18 -0600 (CST) Message-ID: <3E15E938.E1B21014@sun.com> Date: Fri, 03 Jan 2003 13:49:12 -0600 From: Mark Wahl X-Mailer: Mozilla 4.79 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name References: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > "bar" are equal or not. However, the implementation has > no knowledge of which mapping table, or which subset of > a table, of short names to numeric oids applies; the question > of whether "foo" is equal to "bar" is, without context, > Undefined. Common practice for LDAPv3 servers though is to support queries of the form (objectClass=person), and many clients today use objectClass equality matching with non-numeric OIDs. 2252 section 8.1 only said the match was Undefined if the server did not recognize the OID. Mark Wahl Sun Microsystems Inc. From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 16:13:12 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19304 for ; Fri, 3 Jan 2003 16:13:12 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03KrUhO026803; Fri, 3 Jan 2003 21:15:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03Kn1fP024625; Fri, 3 Jan 2003 20:49:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 20:49:01 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03KmuhC024608 for ; Fri, 3 Jan 2003 20:48:57 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h03Kme0a007206; Fri, 3 Jan 2003 20:48:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 03 Jan 2003 12:48:26 -0800 To: Mark Wahl From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: Hallvard B Furuseth , ietf-ldapbis@OpenLDAP.org In-Reply-To: <3E15E938.E1B21014@sun.com> References: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 11:49 AM 1/3/2003, Mark Wahl wrote: >"Kurt D. Zeilenga" wrote: >> "bar" are equal or not. However, the implementation has >> no knowledge of which mapping table, or which subset of >> a table, of short names to numeric oids applies; the question >> of whether "foo" is equal to "bar" is, without context, >> Undefined. > >Common practice for LDAPv3 servers though is to support queries of >the form (objectClass=person), Of course, this is "with context". objectClass is part of the system schema (despite being of usage userApplications) hence the server knows its values refer to object classes. If non-standard object classes are used, there is some ambiguity as to which subschema should be used to map value to an OID. I assume most implementations use the subschema controlling the entry named by the baseObject and don't allow the same name to kind of element (object class, attribute type, matching rule) to appear in a subschema. >and many clients today use objectClass equality matching with non-numeric OIDs. I prefer to use the term 'OID in form'. The key is that matching is done on abstract value, in this case, OIDs. >2252 section 8.1 only said the match was Undefined if the server did not recognize the OID. This statement: If the client supplies a filter using an objectIdentifierMatch whose matchValue oid is in the "descr" form, and the oid is not recognized by the server, then the filter is Undefined. is somewhat problematic (because are ambigious). I think a server should be free to treat the match as Undefined when there is insufficient context to determine whether the assertion value matches an entry (per RFC 2251, 4.5.1). In short, I think we need to be clear as when form SHOULD be used and when it SHOULD NOT be used. I think we all agree that, in LDAP, they SHOULD be used for AttributeTypes appearing in the protocol, values (and assertion values) of the objectClass attribute, and in productions appearing in schema descriptions. How about? MatchingRuleIDs appearing in extensible filters? assertion values of attributeTypes, objectClasses, etc.? Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 17:13:55 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20354 for ; Fri, 3 Jan 2003 17:13:54 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03M3UhG064855; Fri, 3 Jan 2003 22:16:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03LrYeL064416; Fri, 3 Jan 2003 21:53:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 21:53:34 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03LrShC064399 for ; Fri, 3 Jan 2003 21:53:29 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18UZkq-0000rO-00; Fri, 3 Jan 2003 22:53:24 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18UZkq-0003nG-00; Fri, 3 Jan 2003 22:53:24 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Generalized Time/UTC Time need leap seconds Date: Fri, 3 Jan 2003 22:53:24 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Syntaxes] 4.3.13 (Generalized Time) says: second = %x30-36 %x30-39 ; "00" to "59" That should be "00" to "60", since Coordinated Universal Time has leap seconds. See e.g. . -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 17:55:58 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21050 for ; Fri, 3 Jan 2003 17:55:58 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03MhUhO091569; Fri, 3 Jan 2003 22:58:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h03Mfbkr091402; Fri, 3 Jan 2003 22:41:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 3 Jan 2003 22:41:37 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h03MfThC091345; Fri, 3 Jan 2003 22:41:29 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18UaVK-00078P-00; Fri, 3 Jan 2003 23:41:26 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18UaVJ-0003uY-00; Fri, 3 Jan 2003 23:41:25 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: Mark Wahl , ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> References: <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 3 Jan 2003 23:41:25 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: > In short, I think we need to be clear as when form SHOULD > be used and when it SHOULD NOT be used. I think we all agree that, > in LDAP, they SHOULD be used for AttributeTypes appearing in the > protocol, values (and assertion values) of the objectClass attribute, > and in productions appearing in schema descriptions. > > How about? > MatchingRuleIDs appearing in extensible filters? > assertion values of attributeTypes, objectClasses, etc.? I think a general statement is better than listing instances. Something like 4.3.26 (OID): Since a short name can refer to different OIDs in different contexts (e.g. there might be an object class 'x-fubar' and an attribute type 'x-fubar' in a subschema), a server SHOULD NOT allow short names in the OID syntax in contexts where it does not know which the short name represents. 5.2.17 (objectIdentifierMatch): If the asserted value or attribute value is a short name of an OID, and the server does not know which the short name represents but allows such values as attribute values, the match evaluates to Undefiend, even if the asserted value and the attribute value are equal. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 3 19:31:48 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22349 for ; Fri, 3 Jan 2003 19:31:48 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h040XUhG094785; Sat, 4 Jan 2003 00:33:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h040Vi4f094741; Sat, 4 Jan 2003 00:31:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 4 Jan 2003 00:31:44 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h040VdhC094732 for ; Sat, 4 Jan 2003 00:31:39 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h040VM0a009426; Sat, 4 Jan 2003 00:31:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 03 Jan 2003 16:31:09 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 02:41 PM 1/3/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> In short, I think we need to be clear as when form SHOULD >> be used and when it SHOULD NOT be used. I think we all agree that, >> in LDAP, they SHOULD be used for AttributeTypes appearing in the >> protocol, values (and assertion values) of the objectClass attribute, >> and in productions appearing in schema descriptions. >> >> How about? >> MatchingRuleIDs appearing in extensible filters? >> assertion values of attributeTypes, objectClasses, etc.? > >I think a general statement is better than listing instances. While I certainly would prefer a general statement, I'm afraid that different statements might be needed for different instances. >Something like > >4.3.26 (OID): > Since a short name can refer to different OIDs in different > contexts (e.g. there might be an object class 'x-fubar' and an > attribute type 'x-fubar' in a subschema), a server SHOULD NOT > allow short names in the OID syntax in contexts where it does > not know which the short name represents. Doesn't this contradict [Models, 1.3]? >5.2.17 (objectIdentifierMatch): > If the asserted value or attribute value is a short name of an OID, > and the server does not know which the short name > represents but allows such values as attribute values, the match > evaluates to Undefiend, even if the asserted value and the attribute > value are equal. I'm thinking 4.3.26 of [Syntaxes] should say something like: Servers SHOULD prevent values in form from be stored in the directory for which the server is not able to unambiguously determine which OID the represents. and 5.1.17: If the assertion value is presented in form and the implementation is not able to determine which OID the represents, the server SHOULD treat the assertion as being Undefined. That is, if the server cannot determine which OID the refers to, the should be viewed as invalid. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 4 10:42:45 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12453 for ; Sat, 4 Jan 2003 10:42:44 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h04FhVhG018202; Sat, 4 Jan 2003 15:44:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h04FfB9F018177; Sat, 4 Jan 2003 15:41:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 4 Jan 2003 15:41:11 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h04Ff5hC018168 for ; Sat, 4 Jan 2003 15:41:06 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18UqQ2-0006Zn-00; Sat, 4 Jan 2003 16:41:02 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18UqQ1-0006Gy-00; Sat, 4 Jan 2003 16:41:01 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: strange uniqueMemberMatch Date: Sat, 4 Jan 2003 16:41:01 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Syntaxes] 5.2.21 (uniqueMemberMatch) says: The rule evaluates to TRUE if and only if the components of the assertion value and attribute value match according to the distinguishedNameMatch rule and the component is absent from the attribute value or matches the component of the assertion value according to the bitStringMatch rule. Thus, assertion value cn=foo#'0101'B matches attribute value cn=foo. Is that intentional? X.520 paragraph 6.2.11 says the same thing. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 4 10:51:08 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12578 for ; Sat, 4 Jan 2003 10:51:07 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h04FrVhG018449; Sat, 4 Jan 2003 15:53:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h04FnCtN018423; Sat, 4 Jan 2003 15:49:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 4 Jan 2003 15:49:12 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h04Fn3hC018397; Sat, 4 Jan 2003 15:49:04 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18UqXk-0003km-00; Sat, 4 Jan 2003 16:49:00 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18UqXk-0006IP-00; Sat, 4 Jan 2003 16:49:00 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> References: <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sat, 4 Jan 2003 16:49:00 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >> I think a general statement is better than listing instances. > > While I certainly would prefer a general statement, I'm afraid > that different statements might be needed for different instances. Eh? Then why did you too suggest a general statement further down? >> Something like >> >> 4.3.26 (OID): >> Since a short name can refer to different OIDs in different >> contexts (e.g. there might be an object class 'x-fubar' and an >> attribute type 'x-fubar' in a subschema), a server SHOULD NOT >> allow short names in the OID syntax in contexts where it does >> not know which the short name represents. > > Doesn't this contradict [Models, 1.3]? I guess so, but so does your suggestion. Doesn't it say the same thing (except that yours is shorter and better:-)? > I'm thinking 4.3.26 of [Syntaxes] should say something like: > > Servers SHOULD prevent values in form from be > stored in the directory for which the server is not > able to unambiguously determine which OID the > represents. > > and 5.1.17: > If the assertion value is presented in form and > the implementation is not able to determine which OID > the represents, the server SHOULD treat the > assertion as being Undefined. > That is, if the server cannot determine which OID the > refers to, the should be viewed as invalid. Fine. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 4 11:31:10 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13063 for ; Sat, 4 Jan 2003 11:31:09 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h04GXVhG019198; Sat, 4 Jan 2003 16:33:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h04GVFxR019161; Sat, 4 Jan 2003 16:31:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 4 Jan 2003 16:31:15 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h04GVBhC019149 for ; Sat, 4 Jan 2003 16:31:11 GMT (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h04GUs0a015512; Sat, 4 Jan 2003 16:30:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030104080644.02575450@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 04 Jan 2003 08:30:41 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 07:49 AM 1/4/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> I think a general statement is better than listing instances. >> While I certainly would prefer a general statement, I'm afraid >> that different statements might be needed for different instances. >Eh? Then why did you too suggest a general statement further down? Because I prefer general statements as well... but, as I noted, we may have to note some exceptions to them. >> Doesn't this contradict [Models, 1.3]? >I guess so, but so does your suggestion. Yes. So, the next question is, how do we resolve this contradiction? (I'm going to chew on this a bit before attempting to offer a suggestion.) >Doesn't it say the same thing? Basically, yes. From owner-ietf-ldapbis@OpenLDAP.org Sun Jan 5 23:43:02 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15801 for ; Sun, 5 Jan 2003 23:43:01 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h064hxhE049769; Mon, 6 Jan 2003 04:45:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h064c2cr049541; Mon, 6 Jan 2003 04:38:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 6 Jan 2003 04:38:02 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h064bnhC049517 for ; Mon, 6 Jan 2003 04:37:57 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 27656 invoked from network); 6 Jan 2003 04:34:19 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 6 Jan 2003 04:34:19 -0000 Reply-To: From: "Steven Legg" To: "'Hallvard B Furuseth'" Cc: Subject: RE: strange uniqueMemberMatch Date: Mon, 6 Jan 2003 15:36:05 +1100 Message-ID: <00ee01c2b53d$20d2beb0$a518200a@osmium.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 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallvard, Hallvard B Furuseth wrote: > [Syntaxes] 5.2.21 (uniqueMemberMatch) says: > > The rule evaluates to TRUE if and only if the > components of the assertion value and attribute value > match according > to the distinguishedNameMatch rule and the component is > absent from the attribute value or matches the > component > of the assertion value according to the bitStringMatch rule. > > Thus, assertion value cn=foo#'0101'B matches attribute value cn=foo. > Is that intentional? Yes, because ... > X.520 paragraph 6.2.11 says the same thing. The uniqueMemberMatch rule is an equality matching rule that is not commutative, which causes problems in deciding whether attribute values are equal or not when adding or deleting values. I've raised this with the X.500 working group and I'm waiting to see how they resolve it. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 6 00:11:17 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16391 for ; Mon, 6 Jan 2003 00:11:16 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h065DbhE050504; Mon, 6 Jan 2003 05:13:39 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0655mgC050354; Mon, 6 Jan 2003 05:05:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 6 Jan 2003 05:05:48 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h0655hhC050323 for ; Mon, 6 Jan 2003 05:05:44 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 30183 invoked from network); 6 Jan 2003 05:02:15 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 6 Jan 2003 05:02:15 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: objectIdentifierMatch on ambiguous name Date: Mon, 6 Jan 2003 16:04:01 +1100 Message-ID: <00ef01c2b541$0799b210$a518200a@osmium.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 In-Reply-To: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > I'm thinking 4.3.26 of [Syntaxes] should say something like: > > Servers SHOULD prevent values in form from be > stored in the directory for which the server is not > able to unambiguously determine which OID the > represents. > > and 5.1.17: > If the assertion value is presented in form and > the implementation is not able to determine which OID > the represents, the server SHOULD treat the > assertion as being Undefined. > > That is, if the server cannot determine which OID the > refers to, the should be viewed as invalid. This is basically what my server implementation does. It always tries to convert a into a numeric oid, using the context (if available), and throws an "invalid syntax" error if unable to do so. The error will fail an update request, or will cause an assertion to evaluate to undefined. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 6 11:03:51 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06127 for ; Mon, 6 Jan 2003 11:03:50 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h06Frahw071271; Mon, 6 Jan 2003 16:06:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h06Fr69E071245; Mon, 6 Jan 2003 15:53:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 6 Jan 2003 15:53:06 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h06FqwhC071212; Mon, 6 Jan 2003 15:52:59 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18VZYb-0005bp-00; Mon, 6 Jan 2003 16:52:53 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18VZYb-0004y9-00; Mon, 6 Jan 2003 16:52:53 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030104080644.02575450@127.0.0.1> References: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030104080644.02575450@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 6 Jan 2003 16:52:53 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >>> Doesn't this contradict [Models, 1.3]? >>I guess so, but so does your suggestion. > > Yes. So, the next question is, how do we resolve this contradiction? > (I'm going to chew on this a bit before attempting to offer a > suggestion.) I think this statement in [Models] 1.3 > (...) the > encoding option SHOULD be used instead of the > encoding option could get the addition except in contexts where the server cannot unambiguously determine which the represents. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 8 04:32:14 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14956 for ; Wed, 8 Jan 2003 04:32:13 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h089OYhk052180; Wed, 8 Jan 2003 09:34:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0895ge9050629; Wed, 8 Jan 2003 09:05:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 8 Jan 2003 09:05:42 +0000 Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0895ahC050619 for ; Wed, 8 Jan 2003 09:05:37 GMT (envelope-from helmut.volpers@siemens.com) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h0895Yg10340; Wed, 8 Jan 2003 10:05:34 +0100 (MET) Received: from pappel.asw.mchp.siemens.de ([139.25.160.30]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h0895WV18349; Wed, 8 Jan 2003 10:05:33 +0100 (MET) Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 10:05:30 +0100 Message-ID: From: "Volpers, Helmut" To: "'steven.legg@adacel.com.au'" , "'Hallvard B Furuseth'" Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: strange uniqueMemberMatch Date: Wed, 8 Jan 2003 10:05:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Hello, > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Montag, 6. Januar 2003 05:36 > To: 'Hallvard B Furuseth' > Cc: ietf-ldapbis@OpenLDAP.org > Subject: RE: strange uniqueMemberMatch > > > > Hallvard, > > Hallvard B Furuseth wrote: > > [Syntaxes] 5.2.21 (uniqueMemberMatch) says: > > > > The rule evaluates to TRUE if and only if the > > components of the assertion value and attribute value > > match according > > to the distinguishedNameMatch rule and the > component is > > absent from the attribute value or matches the > > component > > of the assertion value according to the bitStringMatch rule. > > > > Thus, assertion value cn=foo#'0101'B matches attribute value cn=foo. > > Is that intentional? No , I think it doesn't match. cn=foo only match cn=foo without the unique ID because "and the uid component is absent" in the rule below. cn=foo#'0101'B matches only cn=foo#'0101'B. X520-6.2.11 The rule returns TRUE if and only if the dn components of the attribute value and the presented value match according to the distinguishedNameMatch rule, and the uid component is absent from the attribute value or matches the corresponding component from the presented value according to the bitStringMatch rule. Helmut > > Yes, because ... > > X.520 paragraph 6.2.11 says the same thing. > > The uniqueMemberMatch rule is an equality matching rule that is not > commutative, which causes problems in deciding whether > attribute values > are equal or not when adding or deleting values. I've raised this with > the X.500 working group and I'm waiting to see how they resolve it. > > Regards, > Steven > From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 8 14:59:18 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04720 for ; Wed, 8 Jan 2003 14:59:18 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h08Jhhho092896; Wed, 8 Jan 2003 20:01:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h08Jh1VN092883; Wed, 8 Jan 2003 19:43:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 8 Jan 2003 19:43:01 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h08JguhC092862 for ; Wed, 8 Jan 2003 19:42:56 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h08Jga0a041749; Wed, 8 Jan 2003 19:42:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030108110558.02312c88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 08 Jan 2003 11:41:02 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: strange uniqueMemberMatch Cc: "'Hallvard B Furuseth'" , In-Reply-To: <00ee01c2b53d$20d2beb0$a518200a@osmium.mtwav.adacel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:36 PM 1/5/2003, Steven Legg wrote: >The uniqueMemberMatch rule is an equality matching rule that is not >commutative, which causes problems in deciding whether attribute values >are equal or not when adding or deleting values. I've raised this with >the X.500 working group and I'm waiting to see how they resolve it. We likely should nudge them on this. The current definition is, I think, problematic because uniqueMember is not single-valued. To resolve this, I think the ITU should change the uniqueMemberMatch semantics to: The rule returns TRUE if and only if the dn components of the attribute value and the presented value match according to the distinguishedNameMatch rule and, if the uid component is present in both values, the uid of the attribute value matches the uid from the presented value according to the bitStringMatch rule. That is, Assertion Value Attribute Value Result cn=foo#'0'B cn=foo#'0'B True cn=foo#'1'B cn=foo#'0'B False (uid mismatch) cn=bar#'0'B cn=foo#'0'B False (dn mismatch) cn=foo cn=foo#'0'B True cn=bar cn=foo#'0'B False (dn mismatch) cn=foo#'0'B cn=foo True cn=foo cn=foo True cn=bar cn=foo False (dn mismatch) Also, I think X.501 should be state that only single-valued attribute types can have non-commutative equality rules. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 8 18:32:03 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13165 for ; Wed, 8 Jan 2003 18:32:03 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h08NXuhE005593; Wed, 8 Jan 2003 23:34:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h08NRvjs005347; Wed, 8 Jan 2003 23:27:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 8 Jan 2003 23:27:57 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h08NRqhC005337 for ; Wed, 8 Jan 2003 23:27:52 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 29152 invoked from network); 8 Jan 2003 23:27:28 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 8 Jan 2003 23:27:28 -0000 Reply-To: From: "Steven Legg" To: "'Volpers, Helmut'" Cc: Subject: RE: strange uniqueMemberMatch Date: Thu, 9 Jan 2003 10:26:05 +1100 Message-ID: <003601c2b76d$51816cf0$a518200a@osmium.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Helmut, Volpers, Helmut wrote: > > -----Original Message----- > > From: Steven Legg [mailto:steven.legg@adacel.com.au] > > Sent: Montag, 6. Januar 2003 05:36 > > To: 'Hallvard B Furuseth' > > Cc: ietf-ldapbis@OpenLDAP.org > > Subject: RE: strange uniqueMemberMatch > > > > > > > > Hallvard, > > > > Hallvard B Furuseth wrote: > > > [Syntaxes] 5.2.21 (uniqueMemberMatch) says: > > > > > > The rule evaluates to TRUE if and only if the > > > > components of the assertion value and attribute value > > > match according > > > to the distinguishedNameMatch rule and the > > component is > > > absent from the attribute value or matches the > > > component > > > of the assertion value according to the bitStringMatch rule. > > > > > > Thus, assertion value cn=foo#'0101'B matches attribute > value cn=foo. > > > Is that intentional? > > No , I think it doesn't match. cn=foo only match cn=foo > without the unique > ID because > > "and the uid component is absent" in the rule below. The rule in X.520 says "absent from the attribute value". It makes no statement about the presence or otherwise of the uid component in the assertion value, so the attribute value cn=foo is matched by both of the assertion values cn=foo#'0101'B and cn=foo. Conversely, the assertion value cn=foo#'0101'B matches both of the attribute values cn=foo and cn=foo#'0101'B. Regards, Steven > > cn=foo#'0101'B matches only cn=foo#'0101'B. > > X520-6.2.11 > > The rule returns TRUE if and only if the dn components of the > attribute > value and the presented value match according to the > distinguishedNameMatch > rule, and the uid component is absent from the attribute > value or matches > the corresponding component from the presented value according to the > bitStringMatch rule. > > Helmut > > > > > Yes, because ... > > > X.520 paragraph 6.2.11 says the same thing. > > > > The uniqueMemberMatch rule is an equality matching rule that is not > > commutative, which causes problems in deciding whether > > attribute values > > are equal or not when adding or deleting values. I've > raised this with > > the X.500 working group and I'm waiting to see how they resolve it. > > > > Regards, > > Steven > > > From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 8 19:21:38 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14610 for ; Wed, 8 Jan 2003 19:21:38 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h090NohE006675; Thu, 9 Jan 2003 00:23:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h090E1u7006547; Thu, 9 Jan 2003 00:14:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 9 Jan 2003 00:14:01 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h090DthC006518 for ; Thu, 9 Jan 2003 00:13:56 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 2347 invoked from network); 9 Jan 2003 00:13:35 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 9 Jan 2003 00:13:35 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: strange uniqueMemberMatch Date: Thu, 9 Jan 2003 11:12:12 +1100 Message-ID: <003701c2b773$c292fc50$a518200a@osmium.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 In-Reply-To: <5.2.0.9.0.20030108110558.02312c88@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > At 08:36 PM 1/5/2003, Steven Legg wrote: > >The uniqueMemberMatch rule is an equality matching rule that is not > >commutative, which causes problems in deciding whether > attribute values > >are equal or not when adding or deleting values. I've raised > this with > >the X.500 working group and I'm waiting to see how they resolve it. > > We likely should nudge them on this. The current > definition is, I think, problematic because uniqueMember > is not single-valued. > > To resolve this, I think the ITU should change the > uniqueMemberMatch semantics to: > The rule returns TRUE if and only if the dn components > of the attribute value and the presented value match > according to the distinguishedNameMatch rule and, if the > uid component is present in both values, the uid of the > attribute value matches the uid from the presented value > according to the bitStringMatch rule. > > That is, > Assertion Value Attribute Value Result > cn=foo#'0'B cn=foo#'0'B True > cn=foo#'1'B cn=foo#'0'B False (uid mismatch) > cn=bar#'0'B cn=foo#'0'B False (dn mismatch) > cn=foo cn=foo#'0'B True > cn=bar cn=foo#'0'B False (dn mismatch) > cn=foo#'0'B cn=foo True > cn=foo cn=foo True > cn=bar cn=foo False (dn mismatch) That's a reasonable way to make the matching rule commutative however it does have the consequence that the uniqueMember attribute cannot simultaneously hold the values cn=foo and cn=foo#'0'B. If the rule is changed to return TRUE if the uid component is absent in both the attribute value and assertion value, or present and the same in both the attribute value and assertion value then both cn=foo and cn=foo#'0'B can simultaneously appear in the uniqueMember attribute. The old semantics of uniqueMemberMatch (or else your suggestion) are suitable to be recommended for approximate matching of the uniqueMember attribute, so as to retain the flexibility of the current matching rule in some form. > Also, I think X.501 should be state that only single-valued > attribute types can have non-commutative equality rules. That, or require all equality matching rules to be commutative. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 8 19:51:34 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15934 for ; Wed, 8 Jan 2003 19:51:33 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h090rohE007315; Thu, 9 Jan 2003 00:53:54 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h090nf6M007267; Thu, 9 Jan 2003 00:49:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 9 Jan 2003 00:49:41 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h090nahC007258 for ; Thu, 9 Jan 2003 00:49:36 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h090nD0a043614; Thu, 9 Jan 2003 00:49:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030108164107.028145c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 08 Jan 2003 16:47:39 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: strange uniqueMemberMatch Cc: In-Reply-To: <003701c2b773$c292fc50$a518200a@osmium.mtwav.adacel.com.au> References: <5.2.0.9.0.20030108110558.02312c88@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Your alternatives seem reasonable as well. Of course, what we need is for the ITU to come out with fixes (to both the general problem and the specific instances) that we can align to. Can you nudge them for response to your previous enquiry? Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 8 20:01:14 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16144 for ; Wed, 8 Jan 2003 20:01:13 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0913ehE007703; Thu, 9 Jan 2003 01:03:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0911B13007643; Thu, 9 Jan 2003 01:01:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 9 Jan 2003 01:01:11 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h09117hC007597 for ; Thu, 9 Jan 2003 01:01:08 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 8542 invoked from network); 9 Jan 2003 01:00:46 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 9 Jan 2003 01:00:46 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: strange uniqueMemberMatch Date: Thu, 9 Jan 2003 11:59:23 +1100 Message-ID: <003801c2b77a$5a5a36b0$a518200a@osmium.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 In-Reply-To: <5.2.0.9.0.20030108164107.028145c0@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > Your alternatives seem reasonable as well. > > Of course, what we need is for the ITU to come out > with fixes (to both the general problem and the > specific instances) that we can align to. Can > you nudge them for response to your previous > enquiry? Yes. Cheers, Steven From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 9 15:56:01 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26053 for ; Thu, 9 Jan 2003 15:56:01 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h09KrFAO001037; Thu, 9 Jan 2003 20:55:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h09Kn0KA000904; Thu, 9 Jan 2003 20:49:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 9 Jan 2003 20:49:00 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h09If2f8001982 for ; Thu, 9 Jan 2003 18:41:03 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18Whbu-0007g3-00 for ietf-ldapbis@openldap.org; Thu, 9 Jan 2003 19:40:58 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18Whbu-000791-00 for ietf-ldapbis@openldap.org; Thu, 9 Jan 2003 19:40:58 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Add and Modify DN Operations in [Protocol]-12 Date: Thu, 9 Jan 2003 19:40:58 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: > 4.7. Add Operation > The entry named in the entry field of the AddRequest MUST NOT exist > for the AddRequest to succeed. The parent of the entry to be added > MUST exist unless the entry being added is the initial vertex of a naming context. Modify DN with newSuperior set should also require that the entry named by newSuperior already exists, unless the new entry name is the initial vertex of a naming context - which would mean that an entry in one naming context is moved to become the initial vertex of another naming context. Or should that be legal at all? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 9 19:34:16 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01688 for ; Thu, 9 Jan 2003 19:34:15 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0A0aJAY008842; Fri, 10 Jan 2003 00:36:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h09Nom3o005875; Thu, 9 Jan 2003 23:50:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 9 Jan 2003 23:50:48 +0000 Received: from cantor.openldap.org (root@cantor.openldap.org [IPv6:2001:4f8:3:ba:206:29ff:fe1f:3f3e]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h09I9Nfa000549; Thu, 9 Jan 2003 18:09:50 GMT (envelope-from hbf@bombur.uio.no) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by cantor.openldap.org (8.12.6/8.12.6) with ESMTP id h09HZs8Y000236; Thu, 9 Jan 2003 17:37:33 GMT (envelope-from hbf@bombur.uio.no) Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h09Fll0Z047273; Thu, 9 Jan 2003 15:47:49 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18Wemo-0005Uc-00; Thu, 9 Jan 2003 16:40:02 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18Wemj-0006kr-00; Thu, 9 Jan 2003 16:39:57 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: steven.legg@adacel.com.au Cc: "Kurt D. Zeilenga" , ietf-ldapbis@OpenLDAP.org Subject: RE: strange uniqueMemberMatch In-Reply-To: <003701c2b773$c292fc50$a518200a@osmium.mtwav.adacel.com.au> References: <5.2.0.9.0.20030108110558.02312c88@127.0.0.1> <003701c2b773$c292fc50$a518200a@osmium.mtwav.adacel.com.au> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 9 Jan 2003 16:39:57 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steven Legg writes: >Kurt D. Zeilenga wrote: >> To resolve this, I think the ITU should change the >> uniqueMemberMatch semantics to: >> (...) > That's a reasonable way to make the matching rule commutative > however it does have the consequence that the uniqueMember > attribute cannot simultaneously hold the values cn=foo and > cn=foo#'0'B. That's better than what we have today: - If cn=foo already exists in an entry, cn=foo#'0'B cannot be added because it tests out to be equal. However, if cn=foo#'0'B already exists, cn=foo _can_ be added. Or maybe the server does it the other way around, the standard allows that too. - Similarly, an add request which adds both values at once will succeed or fail depending on which value is added first. >> Also, I think X.501 should be state that only single-valued >> attribute types can have non-commutative equality rules. > > That, or require all equality matching rules to be commutative. Commutative or take different types (the -firstComponentMatch rules). -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 10 08:41:11 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27886 for ; Fri, 10 Jan 2003 08:41:10 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0ADgoAO032154; Fri, 10 Jan 2003 13:43:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0ADdLhG031898; Fri, 10 Jan 2003 13:39:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 10 Jan 2003 13:39:21 +0000 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0ADcbAM031766 for ; Fri, 10 Jan 2003 13:38:37 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0ADcGkm244182 for ; Fri, 10 Jan 2003 08:38:16 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.52]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0ADcFpH027594 for ; Fri, 10 Jan 2003 08:38:15 -0500 Subject: RE: strange uniqueMemberMatch To: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Fri, 10 Jan 2003 07:38:15 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0|September 26, 2002) at 01/10/2003 07:38:16 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Where are these archived? I was going to look up Kurt's and Steven full notes, but the archives I found at http://www.openldap.org/lists/ietf-ldapbis/ was last updated Jan 3rd. Or the archive only updatede periodically? I always thought that the purpose of the id in uniquemember was to distinguish between different instances (incarnations?) of a given entry. If cn=foo with id #'0'B is defined as a uniquemember, and cn=foo is subsequently deleted and recreated, the new cn=foo will have a different id. Given that only one instance of cn=foo can exist at a time, I don't think it makes sense to have to uniqueMember values in one entry where the only difference is the id (either its value, or its presence/absence). Unfortunately, that results in operation dependent matching behavior: - When adding values to an entry, uniqueMember values match if the dn portion of the values match. - When deleting a value, hmm..., I guess I'd want the entire value to match (both have matching ids or neither has an id) - For search/compare, follow Kurt's suggestion (what I remember of it) For example, the following combinations of values would be illegal on an add (i.e. duplicate values) cn=foo#'0'B cn=foo#'1'B cn=foo#'0'B cn=foo But the first pair of values would not be considered equal in a search or compare operation. John McMeeking >Steven Legg writes: >>Kurt D. Zeilenga wrote: >>> To resolve this, I think the ITU should change the >>> uniqueMemberMatch semantics to: >>> (...) >> That's a reasonable way to make the matching rule commutative >> however it does have the consequence that the uniqueMember >> attribute cannot simultaneously hold the values cn=foo and >> cn=foo#'0'B. > >That's better than what we have today: > >- If cn=foo already exists in an entry, cn=foo#'0'B cannot be > added because it tests out to be equal. However, if cn=foo#'0'B > already exists, cn=foo _can_ be added. Or maybe the server does > it the other way around, the standard allows that too. > >- Similarly, an add request which adds both values at once will > succeed or fail depending on which value is added first. > >>> Also, I think X.501 should be state that only single-valued >>> attribute types can have non-commutative equality rules. >> >> That, or require all equality matching rules to be commutative. > >Commutative or take different types (the -firstComponentMatch rules). > >-- >Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 10 10:40:41 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01032 for ; Fri, 10 Jan 2003 10:40:40 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0AFgcAO044900; Fri, 10 Jan 2003 15:42:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0AFaosV043614; Fri, 10 Jan 2003 15:36:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 10 Jan 2003 15:36:50 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0AFa7AM043454 for ; Fri, 10 Jan 2003 15:36:07 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h0AFZo0a053010; Fri, 10 Jan 2003 15:35:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030110072744.019f1888@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 10 Jan 2003 07:34:17 -0800 To: John McMeeking From: "Kurt D. Zeilenga" Subject: archives (Was: strange uniqueMemberMatch) Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 05:38 AM 1/10/2003, John McMeeking wrote: >Where are these archived? I was going to look up Kurt's and Steven full >notes, but the archives I found at >http://www.openldap.org/lists/ietf-ldapbis/ was last updated Jan 3rd. Or >the archive only updatede periodically? The web archives were not being updated due to a configuration error which I just now corrected. In addition to the web archives, mbox format archives are available through the list management software (using majordomo style requests). Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 10 13:40:48 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10648 for ; Fri, 10 Jan 2003 13:40:48 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0AIgqAS084442; Fri, 10 Jan 2003 18:43:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0AIaaak083109; Fri, 10 Jan 2003 18:36:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 10 Jan 2003 18:36:36 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0AIaXAM083089 for ; Fri, 10 Jan 2003 18:36:34 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18X417-0003Ru-00; Fri, 10 Jan 2003 19:36:29 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18X417-0002fB-00; Fri, 10 Jan 2003 19:36:29 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-ldapbis@OpenLDAP.org Subject: Re: Generalized Time/UTC Time need leap seconds In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 10 Jan 2003 19:36:29 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I wrote: > [Syntaxes] 4.3.13 (Generalized Time) says: > > second = %x30-36 %x30-39 ; "00" to "59" > > That should be "00" to "60", since Coordinated Universal Time has > leap seconds. See e.g. . BTW, I just noticed that the current syntax, and that for minutes, allow 00-69, not 00-59. Try second = %x30-35 %x30-39 / %x36 %x30 ; "00" to "60" -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 10 13:41:02 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10666 for ; Fri, 10 Jan 2003 13:41:01 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0AIgqAQ084442; Fri, 10 Jan 2003 18:43:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0AIeYs8083915; Fri, 10 Jan 2003 18:40:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 10 Jan 2003 18:40:34 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0AIeVAM083874 for ; Fri, 10 Jan 2003 18:40:31 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18X44y-0003dF-00; Fri, 10 Jan 2003 19:40:28 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18X44y-0002fG-00; Fri, 10 Jan 2003 19:40:28 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Add values without equality matching rule Date: Fri, 10 Jan 2003 19:40:28 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Protocol] 4.6 (Modify Operation) says: If an EQUALITY matching rule has not been defined for an attribute type, clients MUST NOT attempt to add or delete individual values of that attribute from an entry using the "add" or "delete" form of a modification, and MUST instead use the "replace" form. Why not? What's the difference between adding values one at a time and all at once? The server has to compare them in any case, to check that two equivalent values are not added. If there is no equality matching rule, it compares the values octet by octet. (See [Models] 2.3.) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Jan 12 18:43:21 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16585 for ; Sun, 12 Jan 2003 18:43:20 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0CNWYB4088472; Sun, 12 Jan 2003 23:45:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0CNVh2c088378; Sun, 12 Jan 2003 23:31:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 12 Jan 2003 23:31:43 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h0CNVcAM088284 for ; Sun, 12 Jan 2003 23:31:39 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 27466 invoked from network); 12 Jan 2003 23:31:17 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 12 Jan 2003 23:31:17 -0000 Reply-To: From: "Steven Legg" To: "'John McMeeking'" Cc: Subject: RE: strange uniqueMemberMatch Date: Mon, 13 Jan 2003 10:29:52 +1100 Message-ID: <004901c2ba92$82b0eda0$a518200a@osmium.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, John McMeeking wrote: > I always thought that the purpose of the id in uniquemember was to > distinguish between different instances (incarnations?) of a > given entry. I would say different instances of the same DN rather than entry. Whether the DN represents the same entity or not is an open question. > If cn=foo with id #'0'B is defined as a uniquemember, and cn=foo is > subsequently deleted and recreated, the new cn=foo will have > a different > id. > Given that only one instance of cn=foo can exist at a > time, I don't > think it makes sense to have to uniqueMember values in one > entry where the > only difference is the id (either its value, or its presence/absence). Only one entry with the name cn=foo can exist at a time but that doesn't mean there aren't applications that need to be aware of the different instances of use of the name cn=foo over time. Such applications may want to store these names in the uniqueMember attribute, or another attribute with the same syntax and equality matching rule. Also, although X.500 expects DNs to uniquely identify entries, in the real world it ain't necessarily so. The unique identifier can be used to disambiguate concurrent uses of the same DN in different servers, and in such cases it is reasonable to have multiple occurrences of the same DN in the uniqueMember attribute. > > Unfortunately, that results in operation dependent matching behavior: I would rather not have matching rules whose semantics vary depending on the context in which they are used. It's messy to describe and causes problems when LDAP extensions create new contexts of usage. Regards, Steven > - When adding values to an entry, uniqueMember values match if the dn > portion of the values match. > - When deleting a value, hmm..., I guess I'd want the entire value to > match (both have matching ids or neither has an id) > - For search/compare, follow Kurt's suggestion (what I > remember of it) > > For example, the following combinations of values would be > illegal on an > add (i.e. duplicate values) > > cn=foo#'0'B > cn=foo#'1'B > > cn=foo#'0'B > cn=foo > > But the first pair of values would not be considered equal in > a search or > compare operation. > > > John McMeeking > > >Steven Legg writes: > >>Kurt D. Zeilenga wrote: > >>> To resolve this, I think the ITU should change the > >>> uniqueMemberMatch semantics to: > >>> (...) > >> That's a reasonable way to make the matching rule commutative > >> however it does have the consequence that the uniqueMember > >> attribute cannot simultaneously hold the values cn=foo and > >> cn=foo#'0'B. > > > >That's better than what we have today: > > > >- If cn=foo already exists in an entry, cn=foo#'0'B cannot be > > added because it tests out to be equal. However, if cn=foo#'0'B > > already exists, cn=foo _can_ be added. Or maybe the server does > > it the other way around, the standard allows that too. > > > >- Similarly, an add request which adds both values at once will > > succeed or fail depending on which value is added first. > > > >>> Also, I think X.501 should be state that only single-valued > >>> attribute types can have non-commutative equality rules. > >> > >> That, or require all equality matching rules to be commutative. > > > >Commutative or take different types (the -firstComponentMatch rules). > > > >-- > >Hallvard > > From owner-ietf-ldapbis@OpenLDAP.org Sun Jan 12 18:50:07 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16661 for ; Sun, 12 Jan 2003 18:50:06 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0CNqZAO092486; Sun, 12 Jan 2003 23:52:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0CNkjn3091346; Sun, 12 Jan 2003 23:46:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 12 Jan 2003 23:46:45 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h0CNkfAM091299 for ; Sun, 12 Jan 2003 23:46:41 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 29445 invoked from network); 12 Jan 2003 23:46:21 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 12 Jan 2003 23:46:21 -0000 Reply-To: From: "Steven Legg" To: "'Hallvard B Furuseth'" Cc: Subject: RE: Generalized Time/UTC Time need leap seconds Date: Mon, 13 Jan 2003 10:44:56 +1100 Message-ID: <004a01c2ba94$9d780590$a518200a@osmium.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallvard, Hallvard B Furuseth wrote: > I wrote: > > [Syntaxes] 4.3.13 (Generalized Time) says: > > > > second = %x30-36 %x30-39 ; > "00" to "59" > > > > That should be "00" to "60", since Coordinated Universal Time has > > leap seconds. See e.g. . > > BTW, I just noticed that the current syntax, and that for minutes, > allow 00-69, not 00-59. Good pickup. I've changed the range of the first digit to %x30-35. The UTCTime type in X.680 doesn't allow for leap seconds (60 seconds is an illegal value). I still have to check whether GeneralizedTime allows it. I've also fixed an error in the ABNF for days "30" and "31". Regards, Steven > Try > > second = %x30-35 %x30-39 / %x36 %x30 ; "00" to "60" > > -- > Hallvard > From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 13 17:40:56 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26792 for ; Mon, 13 Jan 2003 17:40:56 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0DMX3AS014817; Mon, 13 Jan 2003 22:42:56 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0DMGltY013871; Mon, 13 Jan 2003 22:16:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 13 Jan 2003 22:16:46 +0000 Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0DMGgAM013861; Mon, 13 Jan 2003 22:16:43 GMT (envelope-from c.harding@opengroup.org) Received: from CHRIS-H.opengroup.org (dhcp192-153-166-23.rdg.opengroup.org [192.153.166.23]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id h0DMGVO20451; Mon, 13 Jan 2003 22:16:31 GMT Message-Id: <5.1.0.14.1.20030113215419.00b0f858@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 Jan 2003 22:14:22 +0000 To: ldap@umich.edu, openldap-announce@OpenLDAP.org, ietf-ldapbis@OpenLDAP.org From: Chris Harding Subject: Directory Interoperability Forum Hosts its 2nd Plugfest, January 29-31 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Hi - Test your applications for LDAP-Ready compliance! The DIF's 2nd Plugfest offers you the opportunity to test your applications for interoperability with popular servers from CA, IBM, Microsoft, Nexor, Novell, OpenLDAP, Oracle, and Sun, all at the same time and in the same location, and obtain an officially recognized certification your prospects and customers can trust. At our last Plugfest, 8 leading server vendors provided hardware and HP, PeopleSoft and SAP were among the 20 applications that tested and received The Open Group's previous certification Works with LDAP. This event takes place January 29-31, 2003 in Burlingame, CA. The cost to participate is $1,500 (US) dollars, which includes a free pass to The Open Group's Boundaryless Information Flow Conference the following week at the same location. Or, for the first time, you can participate remotely via the Web for $250. More detailed information about this Plugfest and LDAP-Ready Certification is available at the DIF website - see http://www.opengroup.org/dif/dc10/. Register on the web, or contact me. We look forward to seeing you in Burlingame! (I'm sorry if you receive this e-mail more than once. I believe this announcement is of interest to all LDAP developers and, unfortunately, there's no way to avoid duplication between independent lists.) Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== The Open Group Conference Boundaryless Information Flow: Keeping IT Secure San Francisco, CA, USA, 3-7th February http://www.opengroup.org/sfo2003 ======================================================================== From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 14 03:10:59 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18332 for ; Tue, 14 Jan 2003 03:10:58 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0E8CrAO033053; Tue, 14 Jan 2003 08:13:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0E897rq032922; Tue, 14 Jan 2003 08:09:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 14 Jan 2003 08:09:07 +0000 Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0E894AM032909 for ; Tue, 14 Jan 2003 08:09:04 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h0E893Vc016035 for ; Tue, 14 Jan 2003 00:09:03 -0800 Received: from [192.168.1.103] (12-231-112-60.client.attbi.com [12.231.112.60]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h0E891Eo027706 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 14 Jan 2003 00:09:02 -0800 Date: Tue, 14 Jan 2003 00:09:08 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: IETF ldapbis WG Subject: IETF ldapbis WG Last Call: draft-ietf-ldapbis-models-06.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message initiates an LDAPbis Working Group Last Call on the document: LDAP: Directory Information Models 16 December 2002 The purpose of this WG Last Call it to ensure that the Working Group has achieved consensus that the document is suitable for publication as an IETF Draft Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor, Kurt Zeilenga, kurt@OpenLDAP.org. The Last Call period will end on Friday, January 30, 2003. Upon completion of the Last Call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Application Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Draft Standard (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! - RL "Bob" Morgan LDAPbis co-chair From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 16 17:51:25 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25935 for ; Thu, 16 Jan 2003 17:51:24 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0GMqgAQ045087; Thu, 16 Jan 2003 22:53:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0GMppK2045064; Thu, 16 Jan 2003 22:51:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 16 Jan 2003 22:51:51 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0GMplAM045050 for ; Thu, 16 Jan 2003 22:51:48 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18ZIrN-0007Bj-00; Thu, 16 Jan 2003 23:51:41 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ZIrM-00075J-00; Thu, 16 Jan 2003 23:51:40 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: steven.legg@adacel.com.au Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Generalized Time/UTC Time need leap seconds In-Reply-To: <004a01c2ba94$9d780590$a518200a@osmium.mtwav.adacel.com.au> References: <004a01c2ba94$9d780590$a518200a@osmium.mtwav.adacel.com.au> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 16 Jan 2003 23:51:40 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steven Legg writes: >>> [Syntaxes] 4.3.13 (Generalized Time) says: >>> >>> second = %x30-36 %x30-39 ; "00" to "59" >>> >>> That should be "00" to "60", since Coordinated Universal Time has >>> leap seconds. See e.g. . > (...) > The UTCTime type in X.680 doesn't allow for leap seconds (60 seconds > is an illegal value). I still have to check whether GeneralizedTime > allows it. Can you send a bug report for that, and maybe for Generalized Time, to X.680? I don't have X.680, so I don't know where to send the report. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 18 03:54:50 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23890 for ; Sat, 18 Jan 2003 03:54:49 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0I8qjAQ017577; Sat, 18 Jan 2003 08:56:58 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0I8joFW017556; Sat, 18 Jan 2003 08:45:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 18 Jan 2003 08:45:50 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0I8jiAM017544 for ; Sat, 18 Jan 2003 08:45:48 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h0I8jM0a004799; Sat, 18 Jan 2003 08:45:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030117204057.02493d80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 17 Jan 2003 20:56:16 +0100 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Add values without equality matching rule Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 04:40 AM 1/11/2003, Hallvard B Furuseth wrote: >[Protocol] 4.6 (Modify Operation) says: > > If an EQUALITY matching rule has not been defined for an attribute > type, clients MUST NOT attempt to add or delete individual values of > that attribute from an entry using the "add" or "delete" form of a > modification, and MUST instead use the "replace" form. > >Why not? What's the difference between adding values one at a time and >all at once? The server has to compare them in any case, to check that >two equivalent values are not added. If there is no equality matching >rule, it compares the values octet by octet. (See [Models] 2.3.) I think there was odd wording in 2251 regarding what was allowed/disallowed with multiple valued attributes which have no EQUALITY rule and/or where the server doesn't implement that EQUALITY rule. [Models, 2.3] attempts to clarify the data model requirements. Once we have consensus there (which the WG Last Call should determine), I think [Protocol] should be aligned to [Models]. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 18 05:13:42 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24985 for ; Sat, 18 Jan 2003 05:13:42 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0IACjAQ018626; Sat, 18 Jan 2003 10:16:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0IA6hiu018400; Sat, 18 Jan 2003 10:06:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 18 Jan 2003 10:06:43 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0IA6fAM018390 for ; Sat, 18 Jan 2003 10:06:41 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id h0IA6L0a005054; Sat, 18 Jan 2003 10:06:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030118110326.01a04220@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 18 Jan 2003 11:04:50 +0100 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030104080644.02575450@127.0.0.1> <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030104080644.02575450@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I'd like to note, for the purposes of the WG Last Call on [Models], that some clarification to [Models] is needed in this area. Kurt At 01:52 AM 1/7/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>>> Doesn't this contradict [Models, 1.3]? >>>I guess so, but so does your suggestion. >> >> Yes. So, the next question is, how do we resolve this contradiction? >> (I'm going to chew on this a bit before attempting to offer a >> suggestion.) > >I think this statement in [Models] 1.3 > >> (...) the >> encoding option SHOULD be used instead of the >> encoding option > >could get the addition > > except in contexts where the server cannot unambiguously determine > which the represents. > >-- >Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 18 15:51:01 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01077 for ; Sat, 18 Jan 2003 15:51:00 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0IKr6AO029840; Sat, 18 Jan 2003 20:53:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0IKlVli029739; Sat, 18 Jan 2003 20:47:31 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 18 Jan 2003 20:47:31 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0IKlSAM029729 for ; Sat, 18 Jan 2003 20:47:29 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18ZzsC-0005oY-00; Sat, 18 Jan 2003 21:47:24 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ZzsB-0005UD-00; Sat, 18 Jan 2003 21:47:23 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Insignificant space in matching rules Date: Sat, 18 Jan 2003 21:47:23 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Syntaxes] says: > 5.2 Matching Rule Definitions > When evaluating the caseExactIA5Match, caseIgnoreIA5Match, (...) > leading and trailing whitespace is ignored except that a string consisting of only whitespace is treated as a single space. If leading whitespace were ignored in a space-only string, it would be treated as the invalid string "", so the filter would evaluate to undefined. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 18 16:17:06 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01349 for ; Sat, 18 Jan 2003 16:17:05 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0ILDmAa030296; Sat, 18 Jan 2003 21:19:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0IL0MbL029994; Sat, 18 Jan 2003 21:00:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 18 Jan 2003 21:00:22 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0IL0JAM029984 for ; Sat, 18 Jan 2003 21:00:19 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18a04d-0007EN-00; Sat, 18 Jan 2003 22:00:15 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18a04c-0005Ve-00; Sat, 18 Jan 2003 22:00:14 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: [Protocol] result codes Date: Sat, 18 Jan 2003 22:00:14 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Protocol] A.3 says: > compareFalse (5) > Indicates that the operation successfully completes and the > assertion has evaluated to TRUE. > > compareTrue (6) > Indicates that the operation successfully completes and the > assertion has evaluated to FALSE. TRUE and FALSE should be swapped. > adminLimitExceeded (11) > Indicates that an administrative limit has been exceeded. Clarification: Does this mean a time or size limit set by the server? > inappropriateMatching (18) > Indicates that a request cannot be completed due to an > inappropriate matching. Clarification: What is an inappropriate matching? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sat Jan 18 17:00:37 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02006 for ; Sat, 18 Jan 2003 17:00:36 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0IM2pAO031236; Sat, 18 Jan 2003 22:03:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0ILriaH031163; Sat, 18 Jan 2003 21:53:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 18 Jan 2003 21:53:44 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0ILreAM031150 for ; Sat, 18 Jan 2003 21:53:41 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18a0uH-0004PZ-00; Sat, 18 Jan 2003 22:53:37 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18a0uG-0005cg-00; Sat, 18 Jan 2003 22:53:36 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: more draft-zeilenga-ldapbis-strmatch-01.txt problems Date: Sat, 18 Jan 2003 22:53:36 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: > 3.2. Map > > SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code > points are mapped to nothing. (...) The OBJECT REPLACEMENT > CHARACTER (U+FFFC) is mapped to nothing. That means a string consisting only of SOFT HYPHEN is now illegal, since it is mapped to the prohibited string "". Is that intentional? > 3.6. Insignificant Character Removal > 3.6.1. Insignificant Space Removal > 3.6.2. NumericString Insignificant Character Removal > 3.6.3. TelephoneNumber Insignificant Character Removal If a string consists of only spaces (or hyphens for telephone numbers), these are not insignificant: removing them all changes the string from a valid string to the prohibited string "". Such strings should be converted to "", not to "". -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Sun Jan 19 08:25:47 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20132 for ; Sun, 19 Jan 2003 08:25:47 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0JDN9AO051811; Sun, 19 Jan 2003 13:28:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0JDFlig051274; Sun, 19 Jan 2003 13:15:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 19 Jan 2003 13:15:47 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0JDFhAM051264 for ; Sun, 19 Jan 2003 13:15:44 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18aFIb-000164-00 for ietf-ldapbis@openldap.org; Sun, 19 Jan 2003 14:15:41 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18aFIb-0005o0-00 for ietf-ldapbis@OpenLDAP.org; Sun, 19 Jan 2003 14:15:41 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-ldapbis@OpenLDAP.org Subject: Re: Insignificant space in matching rules In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Sun, 19 Jan 2003 14:15:41 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I wrote: >[Syntaxes] says: > >> 5.2 Matching Rule Definitions >> When evaluating the caseExactIA5Match, caseIgnoreIA5Match, (...) >> leading and trailing whitespace is ignored > > except that a string consisting of only whitespace is treated ^^^^^^^^^^^^^^^ That should be "one or more whitespaces". (An empty string consists of only whitespace, but should not be treated as a single space.) > as a single space. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 20 09:21:23 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20844 for ; Mon, 20 Jan 2003 09:21:23 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0KECoAS018027; Mon, 20 Jan 2003 14:23:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0KE2pXV016683; Mon, 20 Jan 2003 14:02:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 20 Jan 2003 14:02:51 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0KE2hAM016639; Mon, 20 Jan 2003 14:02:44 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18acVb-0003EN-00; Mon, 20 Jan 2003 15:02:39 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18acVb-0004mC-00; Mon, 20 Jan 2003 15:02:39 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> References: <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 20 Jan 2003 15:02:39 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >>> How about? >>> MatchingRuleIDs appearing in extensible filters? >>> assertion values of attributeTypes, objectClasses, etc.? >> >>I think a general statement is better than listing instances. > > While I certainly would prefer a general statement, I'm afraid > that different statements might be needed for different instances. I forgot to ask - why? All syntaxes that use OIDs that I can see come with a definition which says which OID name space they apply to, except the OID syntax itself - and the core schema only uses that for the objectClass attribute, which itself provides the namespace. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 20 11:05:41 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22678 for ; Mon, 20 Jan 2003 11:05:40 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0KG2nAQ023927; Mon, 20 Jan 2003 16:08:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0KG29Bq023908; Mon, 20 Jan 2003 16:02:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 20 Jan 2003 16:02:09 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0KG25AM023893 for ; Mon, 20 Jan 2003 16:02:05 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0KG1v8O015047; Mon, 20 Jan 2003 16:01:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030120165139.06826418@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 20 Jan 2003 17:00:28 +0100 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 03:02 PM 1/20/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>>> How about? >>>> MatchingRuleIDs appearing in extensible filters? >>>> assertion values of attributeTypes, objectClasses, etc.? >>> >>>I think a general statement is better than listing instances. >> >> While I certainly would prefer a general statement, I'm afraid >> that different statements might be needed for different instances. > >I forgot to ask - why? Because the existing specification stated a number of special cases... >All syntaxes that use OIDs that I can see come >with a definition which says which OID name space they apply to, Really? I think that most of the definitions of name space are actually quite ambiguous. Consider the assertion (objectClass=foo) in a subtree search where different parts of the subtree are controlled by different subschemas, each with a different definition for foo. (Let's assume the server holds the whole subtree for now.) Is the server to map foo on a per entry basis, or once for the whole operation? >except >the OID syntax itself - and the core schema only uses that for the >objectClass attribute, which itself provides the namespace. I think that an attribute type used in an attribute of a particular entry may actually be insufficient to clear specify a namespace. Consider DNs. Are all names of attribute types appearing in a DN in the same name space, or could each RDN be in a separate name space? From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 20 11:15:20 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22991 for ; Mon, 20 Jan 2003 11:15:19 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0KGCnAQ024341; Mon, 20 Jan 2003 16:17:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0KGA0ue024218; Mon, 20 Jan 2003 16:10:00 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 20 Jan 2003 16:10:00 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0KG9tAM024184; Mon, 20 Jan 2003 16:09:56 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18aeUh-0001YR-00; Mon, 20 Jan 2003 17:09:51 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18aeUh-00057x-00; Mon, 20 Jan 2003 17:09:51 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030120165139.06826418@127.0.0.1> References: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030120165139.06826418@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 20 Jan 2003 17:09:51 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >> All syntaxes that use OIDs that I can see come >> with a definition which says which OID name space they apply to, > > Really? I think that most of the definitions of name space are > actually quite ambiguous. Consider the assertion (objectClass=foo) in > a subtree search where different parts of the subtree are controlled > by different subschemas, each with a different definition for foo. > (Let's assume the server holds the whole subtree for now.) Is the > server to map foo on a per entry basis, or once for the whole > operation? per entry, I think. >> except >> the OID syntax itself - and the core schema only uses that for the >> objectClass attribute, which itself provides the namespace. > > I think that an attribute type used in an attribute of a particular entry > may actually be insufficient to clear specify a namespace. Consider DNs. > Are all names of attribute types appearing in a DN in the same name space, > or could each RDN be in a separate name space? Doesn't matter. If the attribute names are not in the registry or the table of short names or whatever in [DN], short names are not used. The RDN 'objectClass=foo' could be a problem, though. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 24 13:39:45 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28185 for ; Fri, 24 Jan 2003 13:39:45 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0OIWwAY033737; Fri, 24 Jan 2003 18:42:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0OISZIp033427; Fri, 24 Jan 2003 18:28:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 24 Jan 2003 18:28:35 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0OIR9AM033222; Fri, 24 Jan 2003 18:27:10 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18c8Xi-0006iG-00; Fri, 24 Jan 2003 19:27:06 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18c8Xi-0000ac-00; Fri, 24 Jan 2003 19:27:06 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: References: <5.2.0.9.0.20030103160119.024dab60@127.0.0.1> <5.2.0.9.0.20030103120045.024457a8@127.0.0.1> <5.2.0.9.0.20030102084017.01d16830@127.0.0.1> <5.2.0.9.0.20030103071943.031255d8@127.0.0.1> <3E15E938.E1B21014@sun.com> <5.2.0.9.0.20030120165139.06826418@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 24 Jan 2003 19:27:06 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I wrote: >Kurt D. Zeilenga writes: >>> All syntaxes that use OIDs that I can see come >>> with a definition which says which OID name space they apply to, >> >> Really? I think that most of the definitions of name space are >> actually quite ambiguous. Consider the assertion (objectClass=foo) in >> a subtree search where different parts of the subtree are controlled >> by different subschemas, each with a different definition for foo. >> (Let's assume the server holds the whole subtree for now.) Is the >> server to map foo on a per entry basis, or once for the whole >> operation? > > per entry, I think. ...though I wish I didn't:-) In any case, I think the answer to that question belongs in 4.5. Search Operation in [Protocol], not in [Models]. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 27 13:42:17 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22254 for ; Mon, 27 Jan 2003 13:42:16 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RIN4BA077839; Mon, 27 Jan 2003 18:44:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0RIILSV077616; Mon, 27 Jan 2003 18:18:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 27 Jan 2003 18:18:21 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RIIIAM077591 for ; Mon, 27 Jan 2003 18:18:18 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Jan 2003 11:16:23 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 27 Jan 2003 11:17:29 -0700 From: "Jim Sermersheim" To: Subject: Models: Naming Contexts Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit From Models 05 >5.1.2. 'namingContexts' > If the server believes it masters or shadows the entire > directory, the attribute will have a single value, and that value will > be the empty string (indicating the null DN of the root). What if the server is a first level DSA which masters the root of the DIT, and also one or more other naming contexts? I believe this is a flaw and should be corrected to allow the namingContexts attribute to hold values in addition to the empty string. Please refer to X.501 Section 18.5 Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 27 13:46:04 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22420 for ; Mon, 27 Jan 2003 13:46:03 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RIh4Ac079306; Mon, 27 Jan 2003 18:48:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0RIYaI5078687; Mon, 27 Jan 2003 18:34:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 27 Jan 2003 18:34:36 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RIYWAM078660 for ; Mon, 27 Jan 2003 18:34:32 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Jan 2003 11:32:37 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 27 Jan 2003 11:33:46 -0700 From: "Jim Sermersheim" To: Subject: Models: naming context and root DSE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >5. DSA (Server) Informational Model > naming context: A subtree of entries held in a single master DSA. > > The root of the DIT is a DSA-specific Entry (DSE) and not part of any > naming context (or any subtree); each server has different attribute > values in the root DSE. Needs clarification. While the root DSE is not part of any subtree, the root of the DIT may be (though subtrees are *usually* subordinate to the root of the DIT). Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 27 14:10:43 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23161 for ; Mon, 27 Jan 2003 14:10:41 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJD4AQ080754; Mon, 27 Jan 2003 19:13:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0RJ8bil080675; Mon, 27 Jan 2003 19:08:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 27 Jan 2003 19:08:37 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJ8XAM080665 for ; Mon, 27 Jan 2003 19:08:33 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Jan 2003 12:06:52 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 27 Jan 2003 12:08:04 -0700 From: "Jim Sermersheim" To: Subject: Models: Structural Object Class Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >2.4.2. Structural Object Classes It may be good to note (as X.501 does) that an entry's structuralObjectClass attribute may be interrogated to discover which value of the entry's objectClass attribute is the structural object class. Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 27 14:20:37 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23437 for ; Mon, 27 Jan 2003 14:20:37 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJN4AQ081125; Mon, 27 Jan 2003 19:23:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0RJK3Di081037; Mon, 27 Jan 2003 19:20:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 27 Jan 2003 19:20:03 +0000 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJJqAM081003; Mon, 27 Jan 2003 19:19:53 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0RJJUc5037718; Mon, 27 Jan 2003 14:19:30 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.52]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0RJJSYU065194; Mon, 27 Jan 2003 14:19:28 -0500 Subject: Re: Models: Naming Contexts To: "Jim Sermersheim" Cc: ietf-ldapbis@OpenLDAP.org, owner-ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Mon, 27 Jan 2003 13:19:27 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V601_12152002|December 15, 2002) at 01/27/2003 13:19:29 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Jim Sermersheim wrote: >From Models 05 > >>5.1.2. 'namingContexts' >> If the server believes it masters or shadows the entire >> directory, the attribute will have a single value, and that value will >> be the empty string (indicating the null DN of the root). > >What if the server is a first level DSA which masters the root of the >DIT, and also one or more other naming contexts? >I believe this is a flaw and should be corrected to allow the >namingContexts attribute to hold values in addition to the empty >string. I'm having a hard time with the notion of mastering the root of the DIT and some other subtree. Would that be something like: namingContexts: namingContexts: o=my company,c=us ??? If you then create the entry "c=us", would "o=my company,c=us" still be listed as a namingcontext? Since "" is not the root of a DIT subtree, perhaps it would be more appropriate for such servers to return the root entries of subtrees actually present on the server. As new subtrees are created, the namingContexts attribute would be updated accordingly. I'm trying to think of cases where it would be necessary for the server to advertise that "c=au" could be added to the directory, but doesn't yet exist. It seems more useful in this scenario to only list the subtrees that have been created. If the server only holds the subtree "o=my company, c=us" I'd still expect that to be present in the namingcontexts attribute even if the entry doesn't exist. >Please refer to X.501 Section 18.5 > >Jim John McMeeking From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 27 14:30:28 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23691 for ; Mon, 27 Jan 2003 14:30:27 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJX4AQ081486; Mon, 27 Jan 2003 19:33:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0RJNS2S081141; Mon, 27 Jan 2003 19:23:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 27 Jan 2003 19:23:28 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJNOAM081123 for ; Mon, 27 Jan 2003 19:23:24 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Jan 2003 12:21:29 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 27 Jan 2003 12:22:35 -0700 From: "Jim Sermersheim" To: Subject: Models: Subclassing Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 2.4 describes object class subclassing, but should express the effect of subclassing (namely that a subclass inherits the MUST and MAY list(s) of superior object classes in its superclass chain, but does not inherit Name Forms or DIT Content Rules) Section 2.4.2 states "Structural object classes cannot subclass auxiliary object classes." and Section 2.4.3 states "Auxiliary object classes cannot subclass structural object classes.". I can't find these restrictions in X.501--can you point out the reference? Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 27 14:57:11 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24692 for ; Mon, 27 Jan 2003 14:57:10 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJh4B0081941; Mon, 27 Jan 2003 19:59:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0RJemIr081888; Mon, 27 Jan 2003 19:40:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 27 Jan 2003 19:40:48 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RJeiAM081864 for ; Mon, 27 Jan 2003 19:40:44 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Jan 2003 12:38:50 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 27 Jan 2003 12:39:59 -0700 From: "Jim Sermersheim" To: Subject: Re: Models: Naming Contexts Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>> John McMeeking 1/27/03 12:19:27 PM >>> > >Jim Sermersheim wrote: > >>From Models 05 >> >>>5.1.2. 'namingContexts' > >>> If the server believes it masters or shadows the entire >>> directory, the attribute will have a single value, and that value >will >>> be the empty string (indicating the null DN of the root). >> >>What if the server is a first level DSA which masters the root of the >>DIT, and also one or more other naming contexts? >>I believe this is a flaw and should be corrected to allow the >>namingContexts attribute to hold values in addition to the empty >>string. > >I'm having a hard time with the notion of mastering the root of the DIT >and some other subtree. Would that be something like: > namingContexts: > namingContexts: o=my company,c=us >??? Yes, this could happen if it mastered the root as well as o=my company,c=us, but not c=us (it would likely have a subordinate reference to c=us). >If you then create the entry "c=us", would "o=my company,c=us" still be >listed as a namingcontext? If o=my company has no siblings that are mastered elsewhere, I would think that c=us would suffice. But if there are subordinate references under c=us, I would expect to see both values. >Since "" is not the root of a DIT subtree, perhaps it would be more >appropriate for such servers to return the root entries of subtrees >actually present on the server. As new subtrees are created, the >namingContexts attribute would be updated accordingly. Why is "" not the root of a DIT? If I perform a subtree search where the base is "", I am asking to search the entire DIT. See Section 10.2.2 of X.511 (especially "or possibly the root"). I want to know *when* I can search from the DIT root, and I also want to know which contiguous naming contexts a server holds. That said, I do think there's a problem with my original request: A naming context is defined to be a subtree. A server either masters the entire DIT or it doesn't. If a server doesn't master the entire DIT, the empty name cannot be advertised. If a server does master the entire DIT, there shouldn't be namingContexts subordinate to the root. I was mistakenly mixing up my notion of "areas of replication" with namingContexts. I will re-state what I think the real problem is in another mail. >I'm trying to think of cases where it would be necessary for the server >to advertise that "c=au" could be added to the directory, but doesn't >yet exist. It seems more useful in this scenario to only list the subtrees >that have been created. If the server only holds the subtree "o=my >company, >c=us" I'd still expect that to be present in the namingcontexts attribute >even if the entry doesn't exist. I'm getting stuck on a couple things: first, there's no way to advertise names that "could be added". I think you're trying to say that there's an implicit advertisement for this, but I'm not seeing it. Next I don't believe values of the namingContexts attribute should point to non-existent entries in the local DIB fragment. I think I'm missing what you're saying though. >John McMeeking Jim From owner-ietf-ldapbis@OpenLDAP.org Mon Jan 27 15:10:37 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25161 for ; Mon, 27 Jan 2003 15:10:36 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RKD5AS083542; Mon, 27 Jan 2003 20:13:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0RK39wg083202; Mon, 27 Jan 2003 20:03:09 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 27 Jan 2003 20:03:09 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0RK35AM083138 for ; Mon, 27 Jan 2003 20:03:05 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 27 Jan 2003 13:01:10 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 27 Jan 2003 13:02:19 -0700 From: "Jim Sermersheim" To: Subject: Re: Models: Naming Contexts Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm going to flip flop on this one more time--I'm back to my original assertion. Imagine a server that holds [dc=com] [dc=novell,dc=com] [dc=ibm,dc=com] (subordinate reference) [dc=org] (subordinate reference) and [dc=net] (subordinate reference). The server is a first level DSA. I want to know that it masters the root of the tree, regardless of the fact that it has subordinate references directly below the root. I want to be able to search from the root of the tree and receive the search result references for the subref's, intermixed with the search results in the dc=novell,dc=com subtree. Jim >>> John McMeeking 1/27/03 12:19:27 PM >>> > >Jim Sermersheim wrote: > >>From Models 05 >> >>>5.1.2. 'namingContexts' > >>> If the server believes it masters or shadows the entire >>> directory, the attribute will have a single value, and that value >will >>> be the empty string (indicating the null DN of the root). >> >>What if the server is a first level DSA which masters the root of the >>DIT, and also one or more other naming contexts? >>I believe this is a flaw and should be corrected to allow the >>namingContexts attribute to hold values in addition to the empty >>string. > >I'm having a hard time with the notion of mastering the root of the DIT >and some other subtree. Would that be something like: > namingContexts: > namingContexts: o=my company,c=us >??? Yes, this could happen if it mastered the root as well as o=my company,c=us, but not c=us (it would likely have a subordinate reference to c=us). >If you then create the entry "c=us", would "o=my company,c=us" still be >listed as a namingcontext? If o=my company has no siblings that are mastered elsewhere, I would think that c=us would suffice. But if there are subordinate references under c=us, I would expect to see both values. >Since "" is not the root of a DIT subtree, perhaps it would be more >appropriate for such servers to return the root entries of subtrees >actually present on the server. As new subtrees are created, the >namingContexts attribute would be updated accordingly. Why is "" not the root of a DIT? If I perform a subtree search where the base is "", I am asking to search the entire DIT. See Section 10.2.2 of X.511 (especially "or possibly the root"). I want to know *when* I can search from the DIT root, and I also want to know which contiguous naming contexts a server holds. That said, I do think there's a problem with my original request: A naming context is defined to be a subtree. A server either masters the entire DIT or it doesn't. If a server doesn't master the entire DIT, the empty name cannot be advertised. If a server does master the entire DIT, there shouldn't be namingContexts subordinate to the root. I was mistakenly mixing up my notion of "areas of replication" with namingContexts. I will re-state what I think the real problem is in another mail. >I'm trying to think of cases where it would be necessary for the server >to advertise that "c=au" could be added to the directory, but doesn't >yet exist. It seems more useful in this scenario to only list the subtrees >that have been created. If the server only holds the subtree "o=my >company, >c=us" I'd still expect that to be present in the namingcontexts attribute >even if the entry doesn't exist. I'm getting stuck on a couple things: first, there's no way to advertise names that "could be added". I think you're trying to say that there's an implicit advertisement for this, but I'm not seeing it. Next I don't believe values of the namingContexts attribute should point to non-existent entries in the local DIB fragment. I think I'm missing what you're saying though. >John McMeeking Jim From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 10:11:30 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27423 for ; Tue, 28 Jan 2003 10:11:29 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SFD6AQ042463; Tue, 28 Jan 2003 15:13:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SF360Q042042; Tue, 28 Jan 2003 15:03:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 15:03:06 +0000 Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [192.80.55.70]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SF32AM042030 for ; Tue, 28 Jan 2003 15:03:02 GMT (envelope-from kdally@mitre.org) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id h0SF2xf20853; Tue, 28 Jan 2003 10:02:59 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id h0SEvti24241; Tue, 28 Jan 2003 09:57:56 -0500 (EST) Received: from mm109527-2k.mitre.org (128.29.3.52) by mailhub2.mitre.org with SMTP id 909424; Tue, 28 Jan 2003 09:57:50 -0500 Message-ID: <3E369A6F.E9FE9F58@mitre.org> Date: Tue, 28 Jan 2003 09:57:51 -0500 From: Kathy Dally Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Subclassing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jim! There are no restrictions in X.501 on structural and auxiliary classes being subclasses of one another. Although it doesn't make a lot of sense to me, I have seen cases where several structural object classes have an auxiliary as the superclass. I can't think of an example of the reverse, off hand. Thanks, Kathy Jim Sermersheim wrote: > > Section 2.4 describes object class subclassing, but should express the > effect of subclassing (namely that a subclass inherits the MUST and MAY > list(s) of superior object classes in its superclass chain, but does not > inherit Name Forms or DIT Content Rules) > > Section 2.4.2 states "Structural object classes cannot subclass > auxiliary object classes." and Section 2.4.3 states "Auxiliary object > classes cannot subclass structural object classes.". I can't find these > restrictions in X.501--can you point out the reference? > > Jim From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 11:13:25 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29519 for ; Tue, 28 Jan 2003 11:13:24 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SG3SAW046552; Tue, 28 Jan 2003 16:15:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SFmSHe045372; Tue, 28 Jan 2003 15:48:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 15:48:28 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SFmMAM045344 for ; Tue, 28 Jan 2003 15:48:23 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18dXyC-0002Vj-00; Tue, 28 Jan 2003 16:48:16 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18dXyB-0005qt-00; Tue, 28 Jan 2003 16:48:15 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Naming Contexts In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 28 Jan 2003 16:48:15 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim writes: > If a server does master the entire DIT, there shouldn't be > namingContexts subordinate to the root. What if the server masters "" and o=foo,c=US, but not c=US? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 11:51:02 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00983 for ; Tue, 28 Jan 2003 11:51:01 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SGr7AQ050366; Tue, 28 Jan 2003 16:53:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SGlkGw050170; Tue, 28 Jan 2003 16:47:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 16:47:46 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SGlgAM050153 for ; Tue, 28 Jan 2003 16:47:43 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Jan 2003 09:45:47 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 28 Jan 2003 09:46:50 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: Models: Naming Contexts Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Right, I caught something like that with my subsequent message--thanks. Jim >>> Hallvard B Furuseth 1/28/03 8:48:15 AM >>> Jim Sermersheim writes: > If a server does master the entire DIT, there shouldn't be > namingContexts subordinate to the root. What if the server masters "" and o=foo,c=US, but not c=US? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 12:48:11 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02203 for ; Tue, 28 Jan 2003 12:48:09 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SHh6Ag054229; Tue, 28 Jan 2003 17:50:42 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SHWUcJ053522; Tue, 28 Jan 2003 17:32:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 17:32:30 +0000 Received: from srvmaddog.metasolv.com (mail.metasolv.com [12.105.131.5]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SHWQAM053500 for ; Tue, 28 Jan 2003 17:32:26 GMT (envelope-from mpana@metasolv.com) Received: by mail.metasolv.com with Internet Mail Service (5.5.2655.55) id ; Tue, 28 Jan 2003 11:34:03 -0600 Message-ID: From: "Pana, Mircea" To: "'Kathy Dally'" , Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: RE: Models: Subclassing Date: Tue, 28 Jan 2003 11:31:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6F3.2056D7B0" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C6F3.2056D7B0 Content-Type: text/plain X501 section 8.3.2 recommends: "An object or alias entry is characterised by precisely one structural object class superclass chain which has a single structural object class as the most subordinate object class." Doesn't this imply that an auxiliary object class can not subclass a structural object class? Thanks, Mircea. -----Original Message----- From: Kathy Dally [mailto:kdally@mitre.org] Sent: Tuesday, January 28, 2003 9:58 AM To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Subclassing Hi Jim! There are no restrictions in X.501 on structural and auxiliary classes being subclasses of one another. Although it doesn't make a lot of sense to me, I have seen cases where several structural object classes have an auxiliary as the superclass. I can't think of an example of the reverse, off hand. Thanks, Kathy Jim Sermersheim wrote: > > Section 2.4 describes object class subclassing, but should express the > effect of subclassing (namely that a subclass inherits the MUST and MAY > list(s) of superior object classes in its superclass chain, but does not > inherit Name Forms or DIT Content Rules) > > Section 2.4.2 states "Structural object classes cannot subclass > auxiliary object classes." and Section 2.4.3 states "Auxiliary object > classes cannot subclass structural object classes.". I can't find these > restrictions in X.501--can you point out the reference? > > Jim ------_=_NextPart_001_01C2C6F3.2056D7B0 Content-Type: text/html RE: Models: Subclassing

X501 section 8.3.2 recommends:
  "An object or alias entry is characterised by precisely
   one structural object class superclass chain which has
   a single structural object class as the most subordinate
   object class."

Doesn't this imply that an auxiliary object class can not
subclass a structural object class?

Thanks,
Mircea.

-----Original Message-----
From: Kathy Dally [mailto:kdally@mitre.org]
Sent: Tuesday, January 28, 2003 9:58 AM
To: Jim Sermersheim
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Models: Subclassing


Hi Jim!

There are no restrictions in X.501 on structural and auxiliary classes
being subclasses of one another.  Although it doesn't make a lot of
sense to me, I have seen cases where several structural object classes
have an auxiliary as the superclass.  I can't think of an example of the
reverse, off hand.

Thanks,
Kathy


Jim Sermersheim wrote:
>
> Section 2.4 describes object class subclassing, but should express the
> effect of subclassing (namely that a subclass inherits the MUST and MAY
> list(s) of superior object classes in its superclass chain, but does not
> inherit Name Forms or DIT Content Rules)
>
> Section 2.4.2 states "Structural object classes cannot subclass
> auxiliary object classes." and Section 2.4.3 states "Auxiliary object
> classes cannot subclass structural object classes.". I can't find these
> restrictions in X.501--can you point out the reference?
>
> Jim

------_=_NextPart_001_01C2C6F3.2056D7B0-- From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 12:48:23 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02223 for ; Tue, 28 Jan 2003 12:48:22 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SHh6Ae054229; Tue, 28 Jan 2003 17:50:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SHdPMF053998; Tue, 28 Jan 2003 17:39:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 17:39:25 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SHdLAM053972 for ; Tue, 28 Jan 2003 17:39:21 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Jan 2003 10:37:26 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 28 Jan 2003 10:38:38 -0700 From: "Jim Sermersheim" To: , , Subject: RE: Models: Subclassing Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit From that, I only see that the most subordinate object class must be structural, and that there can only be one chain (though there can be multiple inheriitance), there cannot be two completely different chains (resulting in multiple structural most-subordinate object classes). It cannot mean that all superclasses are structural as that would nullify the use of abstract object classes. Jim >>> "Pana, Mircea" 1/28/03 10:31:44 AM >>> X501 section 8.3.2 recommends: "An object or alias entry is characterised by precisely one structural object class superclass chain which has a single structural object class as the most subordinate object class." Doesn't this imply that an auxiliary object class can not subclass a structural object class? Thanks, Mircea. -----Original Message----- From: Kathy Dally [mailto:kdally@mitre.org] Sent: Tuesday, January 28, 2003 9:58 AM To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Subclassing Hi Jim! There are no restrictions in X.501 on structural and auxiliary classes being subclasses of one another. Although it doesn't make a lot of sense to me, I have seen cases where several structural object classes have an auxiliary as the superclass. I can't think of an example of the reverse, off hand. Thanks, Kathy Jim Sermersheim wrote: > > Section 2.4 describes object class subclassing, but should express the > effect of subclassing (namely that a subclass inherits the MUST and MAY > list(s) of superior object classes in its superclass chain, but does not > inherit Name Forms or DIT Content Rules) > > Section 2.4.2 states "Structural object classes cannot subclass > auxiliary object classes." and Section 2.4.3 states "Auxiliary object > classes cannot subclass structural object classes.". I can't find these > restrictions in X.501--can you point out the reference? > > Jim From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 13:06:34 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02528 for ; Tue, 28 Jan 2003 13:06:33 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SHr6B6055201; Tue, 28 Jan 2003 18:09:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SHmZrB054744; Tue, 28 Jan 2003 17:48:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 17:48:35 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SHmVAM054734 for ; Tue, 28 Jan 2003 17:48:31 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0SHmL8O068434; Tue, 28 Jan 2003 17:48:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030128091704.01a0d9d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 09:46:34 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Models: Structural Object Class Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 11:08 AM 1/27/2003, Jim Sermersheim wrote: >>2.4.2. Structural Object Classes > >It may be good to note (as X.501 does) that an entry's >structuralObjectClass attribute may be interrogated to discover which >value of the entry's objectClass attribute is the structural object >class. And 'governingStructureRule', too? 3.4.5. 'structuralObjectClass' The attribute indicates the structural object class of the entry. ( 2.5.21.9 NAME 'structuralObjectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes]. 3.4.6. 'governingStructureRule' The attribute indicates the structure rule governing the entry. ( 2.5.21.10 NAME 'governingStructureRule' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'integerMatch' matching rule and INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes]. Personally, I don't have a problem adding both of these as they address technical omissions. One, however, could consider the above to be 'LDAP non-"core" schema' [LDAPBIS charter]. This charter issue I defer to Bob (who acts as sole chair in regards to this I-D). Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 13:33:10 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03199 for ; Tue, 28 Jan 2003 13:33:09 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SID7BE056760; Tue, 28 Jan 2003 18:35:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SIBWQM056680; Tue, 28 Jan 2003 18:11:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 18:11:32 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SIBSAM056662 for ; Tue, 28 Jan 2003 18:11:28 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18daCj-0003E9-00; Tue, 28 Jan 2003 19:11:25 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18daCi-0006AW-00; Tue, 28 Jan 2003 19:11:24 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Protocol: Graceful TLS Closure and outstanding operations Date: Tue, 28 Jan 2003 19:11:24 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Protocol] 4.13.3.1 says that the server may initiate graceful TLS closure, which leaves the LDAP session intact. I think outstanding operations MUST then be abandoned, and responses to operations that could not be abandoned MUST NOT be sent after the TLS closure. The responses might contain sensitive information. Which is another reason why client-initiated TLS closure should do the same, for symmetry:-) BTW, the previous discussion about TLS closure stopped without resolution, see http://www.openldap.org/lists/ietf-ldapbis/200212/msg00007.html -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 13:33:11 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03200 for ; Tue, 28 Jan 2003 13:33:09 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SID7BG056760; Tue, 28 Jan 2003 18:35:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SIAlOW056613; Tue, 28 Jan 2003 18:10:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 18:10:47 +0000 Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SIAfAM056576 for ; Tue, 28 Jan 2003 18:10:42 GMT (envelope-from Chris.Oliva@entrust.com) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Tue, 28 Jan 2003 13:10:11 -0500 Message-ID: From: Christopher Oliva To: "'Jim Sermersheim'" , ietf-ldapbis@OpenLDAP.org Subject: RE: Models: Naming Contexts Date: Tue, 28 Jan 2003 13:10:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6F8.7F314680" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C6F8.7F314680 Content-Type: text/plain A couple of comments on this: - the suggestion would allow the client to recognize a server as a first level DSA but I'm not sure where this term is defined in the specs and if the requirements for claiming that role have been established. It's defined in X.501 as not allowing a superior reference and holding a complete list of references to naming contexts below the root. - I'm not sure what a client will gain by detecting the root in the namingContexts attribute (according to the new proposal). Because, a server might still have references to naming contexts it doesn't master or shadow. I suppose this will tell the client to stop its search after querying a first level DSA and receiving an "entry not found" error. Otherwise the client could continue its search to another server (to which it has acquired a reference). Perhaps this client behaviour should be documented - although I'm not sure how many existing clients would conform to that. Chris. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Monday, January 27, 2003 3:02 PM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Naming Contexts I'm going to flip flop on this one more time--I'm back to my original assertion. Imagine a server that holds [dc=com] [dc=novell,dc=com] [dc=ibm,dc=com] (subordinate reference) [dc=org] (subordinate reference) and [dc=net] (subordinate reference). The server is a first level DSA. I want to know that it masters the root of the tree, regardless of the fact that it has subordinate references directly below the root. I want to be able to search from the root of the tree and receive the search result references for the subref's, intermixed with the search results in the dc=novell,dc=com subtree. Jim >>> John McMeeking 1/27/03 12:19:27 PM >>> > >Jim Sermersheim wrote: > >>From Models 05 >> >>>5.1.2. 'namingContexts' > >>> If the server believes it masters or shadows the entire >>> directory, the attribute will have a single value, and that value >will >>> be the empty string (indicating the null DN of the root). >> >>What if the server is a first level DSA which masters the root of the >>DIT, and also one or more other naming contexts? >>I believe this is a flaw and should be corrected to allow the >>namingContexts attribute to hold values in addition to the empty >>string. > >I'm having a hard time with the notion of mastering the root of the DIT >and some other subtree. Would that be something like: > namingContexts: > namingContexts: o=my company,c=us >??? Yes, this could happen if it mastered the root as well as o=my company,c=us, but not c=us (it would likely have a subordinate reference to c=us). >If you then create the entry "c=us", would "o=my company,c=us" still be >listed as a namingcontext? If o=my company has no siblings that are mastered elsewhere, I would think that c=us would suffice. But if there are subordinate references under c=us, I would expect to see both values. >Since "" is not the root of a DIT subtree, perhaps it would be more >appropriate for such servers to return the root entries of subtrees >actually present on the server. As new subtrees are created, the >namingContexts attribute would be updated accordingly. Why is "" not the root of a DIT? If I perform a subtree search where the base is "", I am asking to search the entire DIT. See Section 10.2.2 of X.511 (especially "or possibly the root"). I want to know *when* I can search from the DIT root, and I also want to know which contiguous naming contexts a server holds. That said, I do think there's a problem with my original request: A naming context is defined to be a subtree. A server either masters the entire DIT or it doesn't. If a server doesn't master the entire DIT, the empty name cannot be advertised. If a server does master the entire DIT, there shouldn't be namingContexts subordinate to the root. I was mistakenly mixing up my notion of "areas of replication" with namingContexts. I will re-state what I think the real problem is in another mail. >I'm trying to think of cases where it would be necessary for the server >to advertise that "c=au" could be added to the directory, but doesn't >yet exist. It seems more useful in this scenario to only list the subtrees >that have been created. If the server only holds the subtree "o=my >company, >c=us" I'd still expect that to be present in the namingcontexts attribute >even if the entry doesn't exist. I'm getting stuck on a couple things: first, there's no way to advertise names that "could be added". I think you're trying to say that there's an implicit advertisement for this, but I'm not seeing it. Next I don't believe values of the namingContexts attribute should point to non-existent entries in the local DIB fragment. I think I'm missing what you're saying though. >John McMeeking Jim ------_=_NextPart_001_01C2C6F8.7F314680 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Models: Naming Contexts

A couple of comments on this:

- the suggestion would allow the client to recognize = a server as a first level DSA but I'm not sure where this term is = defined in the specs and if the requirements for claiming that role = have been established. It's defined in X.501 as not allowing a superior = reference and holding a complete list of references to naming contexts = below the root.

- I'm not sure what a client will gain by detecting = the root in the namingContexts attribute (according to the new = proposal). Because, a server might still have references to naming = contexts it doesn't master or shadow. I suppose this will tell the = client to stop its search after querying a first level DSA and = receiving an "entry not found" error. Otherwise the client = could continue its search to another server (to which it has acquired a = reference). Perhaps this client behaviour should be documented - = although I'm not sure how many existing clients would conform to = that.

Chris.


-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com]
Sent: Monday, January 27, 2003 3:02 PM
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: Models: Naming Contexts


I'm going to flip flop on this one more time--I'm = back to my original
assertion. Imagine a server that holds [dc=3Dcom] = [dc=3Dnovell,dc=3Dcom]
[dc=3Dibm,dc=3Dcom] (subordinate reference) = [dc=3Dorg] (subordinate reference)
and [dc=3Dnet] (subordinate reference).

The server is a first level DSA. I want to know that = it masters the
root of the tree, regardless of the fact that it has = subordinate
references directly below the root. I want to be = able to search from the
root of the tree and receive the search result = references for the
subref's, intermixed with the search results in the = dc=3Dnovell,dc=3Dcom
subtree.

Jim


<previous message below>

>>> John McMeeking = <jmcmeek@us.ibm.com> 1/27/03 12:19:27 PM >>>
>
>Jim Sermersheim wrote:
>
>>From Models 05
>>
>>>5.1.2. 'namingContexts'
><snip>
>>>  If the server believes it masters = or shadows the entire
>>>  directory, the attribute will = have a single value, and that value
>will
>>>  be the empty string (indicating = the null DN of the root).
>>
>>What if the server is a first level DSA = which masters the root of
the
>>DIT, and also one or more other naming = contexts?
>>I believe this is a flaw and should be = corrected to allow the
>>namingContexts attribute to hold values in = addition to the empty
>>string.
>
>I'm having a hard time with the notion of = mastering the root of the
DIT
>and some other subtree.  Would that be = something like:
>  namingContexts: <empty = string>
>  namingContexts: o=3Dmy = company,c=3Dus
>???

Yes, this could happen if it mastered the root as = well as o=3Dmy
company,c=3Dus, but not c=3Dus (it would likely have = a subordinate reference
to c=3Dus).

>If you then create the entry "c=3Dus", = would "o=3Dmy company,c=3Dus" still
be
>listed as a namingcontext?

If o=3Dmy company has no siblings that are mastered = elsewhere, I would
think that c=3Dus would suffice. But if there are = subordinate references
under c=3Dus, I would expect to see both = values.

>Since "" is not the root of a DIT = subtree, perhaps it would be more
>appropriate for such servers to return the root = entries of subtrees
>actually present on the server.  As new = subtrees are created, the
>namingContexts attribute would be updated = accordingly.

Why is "" not the root of a DIT? If I = perform a subtree search where
the base is "", I am asking to search the = entire DIT. See Section 10.2.2
of X.511 (especially "or possibly the = root"). I want to know *when* I
can search from the DIT root, and I also want to = know which contiguous
naming contexts a server holds.

That said, I do think there's a problem with my = original request:

A naming context is defined to be a subtree. A server = either masters
the entire DIT or it doesn't. If a server doesn't = master the entire DIT,
the empty name cannot be advertised. If a server = does master the entire
DIT, there shouldn't be namingContexts subordinate = to the root. I was
mistakenly mixing up my notion of "areas of = replication" with
namingContexts. I will re-state what I think the = real problem is in
another mail.

>I'm trying to think of cases where it would be = necessary for the
server
>to advertise that "c=3Dau" could be = added to the directory, but doesn't
>yet exist.  It seems more useful in this = scenario to only list the
subtrees
>that have been created.  If the server only = holds the subtree "o=3Dmy
>company,
>c=3Dus" I'd still expect that to be present = in the namingcontexts
attribute
>even if the entry doesn't exist.

I'm getting stuck on a couple things: first, there's = no way to
advertise names that "could be added". I = think you're trying to say that
there's an implicit advertisement for this, but I'm = not seeing it. Next
I don't believe values of the namingContexts = attribute should point to
non-existent entries in the local DIB fragment. I = think I'm missing what
you're saying though.

>John McMeeking

Jim

------_=_NextPart_001_01C2C6F8.7F314680-- From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 14:18:36 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04321 for ; Tue, 28 Jan 2003 14:18:34 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SJ36B0060219; Tue, 28 Jan 2003 19:20:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SJ1tK6060169; Tue, 28 Jan 2003 19:01:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 19:01:55 +0000 Received: from cosium01.intelliden.net (cosium01.intelliden.net [12.41.186.248]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SJ1pAM060151 for ; Tue, 28 Jan 2003 19:01:51 GMT (envelope-from John.Strassner@intelliden.com) Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 12:01:46 -0700 Message-ID: <11AB6A3E2294E94DB47B67E1BC7ECFD812EF7E@cosium02> From: John Strassner To: "'Kathy Dally'" , Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Models: Subclassing Date: Tue, 28 Jan 2003 12:01:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6FF.B3A28D50" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C6FF.B3A28D50 Content-Type: text/plain I'm sorry, but this is absurd. Having an aux class, which is the object equivalent of a capsule, serve as the superclass for a structural entry doesn't make sense at all. Even if X.501 doesn't prevent it, we should. And yes, sadly, I've seen plenty of examples. None of them, however, could be justified. ;-) regards, John John Strassner Chief Strategy Officer Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 USA phone: +1.719.785.0648 FAX: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Kathy Dally [mailto:kdally@mitre.org] Sent: Tuesday, January 28, 2003 7:58 AM To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Subclassing Hi Jim! There are no restrictions in X.501 on structural and auxiliary classes being subclasses of one another. Although it doesn't make a lot of sense to me, I have seen cases where several structural object classes have an auxiliary as the superclass. I can't think of an example of the reverse, off hand. Thanks, Kathy Jim Sermersheim wrote: > > Section 2.4 describes object class subclassing, but should express the > effect of subclassing (namely that a subclass inherits the MUST and > MAY > list(s) of superior object classes in its superclass chain, but does not > inherit Name Forms or DIT Content Rules) > > Section 2.4.2 states "Structural object classes cannot subclass > auxiliary object classes." and Section 2.4.3 states "Auxiliary object > classes cannot subclass structural object classes.". I can't find > these restrictions in X.501--can you point out the reference? > > Jim ------_=_NextPart_001_01C2C6FF.B3A28D50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Models: Subclassing

I'm sorry, but this is absurd. Having an aux class, = which is the object equivalent of a capsule, serve as the superclass = for a structural entry doesn't make sense at all. Even if X.501 doesn't = prevent it, we should.

And yes, sadly, I've seen plenty of examples. None of = them, however, could be justified. ;-)

regards,
John
 
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO  80903  USA
phone: +1.719.785.0648
  FAX: +1.719.785.0644
email: john.strassner@intelliden.com
 


-----Original Message-----
From: Kathy Dally [mailto:kdally@mitre.org]
Sent: Tuesday, January 28, 2003 7:58 AM
To: Jim Sermersheim
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Models: Subclassing


Hi Jim!

There are no restrictions in X.501 on structural and = auxiliary classes being subclasses of one another.  Although it = doesn't make a lot of sense to me, I have seen cases where several = structural object classes have an auxiliary as the superclass.  I = can't think of an example of the reverse, off hand.

Thanks,
Kathy


Jim Sermersheim wrote:
>
> Section 2.4 describes object class subclassing, = but should express the
> effect of subclassing (namely that a subclass = inherits the MUST and
> MAY
> list(s) of superior object classes in its = superclass chain, but does not
> inherit Name Forms or DIT Content Rules)
>
> Section 2.4.2 states "Structural object = classes cannot subclass
> auxiliary object classes." and Section = 2.4.3 states "Auxiliary object
> classes cannot subclass structural object = classes.". I can't find
> these restrictions in X.501--can you point out = the reference?
>
> Jim

------_=_NextPart_001_01C2C6FF.B3A28D50-- From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 14:31:27 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04624 for ; Tue, 28 Jan 2003 14:31:26 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SJXkAM061994; Tue, 28 Jan 2003 19:33:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SJ91Wj060683; Tue, 28 Jan 2003 19:09:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 19:09:01 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SJ8vAM060673 for ; Tue, 28 Jan 2003 19:08:57 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0SJ8l8O069102; Tue, 28 Jan 2003 19:08:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030128100431.02b3e360@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 11:06:59 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Models: Subclassing Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 11:22 AM 1/27/2003, Jim Sermersheim wrote: >Section 2.4 describes object class subclassing, but should express the >effect of subclassing (namely that a subclass inherits the MUST and MAY >list(s) of superior object classes in its superclass chain, but does not >inherit Name Forms or DIT Content Rules) > >Section 2.4.2 states "Structural object classes cannot subclass >auxiliary object classes." and Section 2.4.3 states "Auxiliary object >classes cannot subclass structural object classes.". I can't find these >restrictions in X.501--can you point out the reference? You won't find any clear, explicit statement in X.501 regarding this. I added the above statements to address what I consider to be a technical omission in the existing specification. The alternative would be describe the semantics of such subclassing. I didn't take this alternative as such subclassing makes no sense to me. Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 14:52:17 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05156 for ; Tue, 28 Jan 2003 14:52:16 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SJh6AW062587; Tue, 28 Jan 2003 19:54:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SJdlux062482; Tue, 28 Jan 2003 19:39:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 19:39:47 +0000 Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SJdeAM062390; Tue, 28 Jan 2003 19:39:40 GMT (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h0SJdO509994; Tue, 28 Jan 2003 11:39:24 -0800 (PST) Received: from netscape.com ([10.169.192.59]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H9FVXE02.J0W; Tue, 28 Jan 2003 11:39:14 -0800 Message-ID: <3E36DC61.3050608@netscape.com> Date: Tue, 28 Jan 2003 14:39:13 -0500 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Structural Object Class References: <5.2.0.9.0.20030128091704.01a0d9d8@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030128091704.01a0d9d8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > Personally, I don't have a problem adding both of these as they > address technical omissions. One, however, could consider the > above to be 'LDAP non-"core" schema' [LDAPBIS charter]. This > charter issue I defer to Bob (who acts as sole chair in regards > to this I-D). I view both of these (structuralObjectClass and governingStructureRule) as non-core schema (extensions to LDAPv3, not core). That does not mean they are not useful to some applications though. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 15:34:02 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06516 for ; Tue, 28 Jan 2003 15:33:59 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SKX7AQ065007; Tue, 28 Jan 2003 20:36:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SKQDU7064765; Tue, 28 Jan 2003 20:26:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 20:26:13 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SKQ9AM064744 for ; Tue, 28 Jan 2003 20:26:09 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0SKPx8O069737; Tue, 28 Jan 2003 20:25:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030128114853.02bfe088@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 12:24:12 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Models: Naming Contexts Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:17 AM 1/27/2003, Jim Sermersheim wrote: >>From Models 05 > >>5.1.2. 'namingContexts' > >> If the server believes it masters or shadows the entire >> directory, the attribute will have a single value, and that value >will >> be the empty string (indicating the null DN of the root). > >What if the server is a first level DSA which masters the root of the >DIT, and also one or more other naming contexts? Well, this sentence wouldn't apply in this case. So, taking the specification literally, the namingContext attribute would have one value for each naming contexts it masters or shadows, the context prefix of the naming context. This would NOT include "" as "" is not a valid context prefix. >I believe this is a flaw and should be corrected to allow the >namingContexts attribute to hold values in addition to the empty >string. Please refer to X.501 Section 18.5 I have a couple of alternatives approaches which could be taken 1) replace first paragraph of 5.1.2 with: The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server is a first-level DSA [X.501], it should list (in addition) an empty string (indicating the root of the DIT). If the server does not master or shadow any information (e.g. it is an LDAP gateway to a public X.500 directory) this attribute will be absent. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string (indicating the root of the DIT). This attribute allows a client to choose suitable base objects for searching when it has contacted a server. and then noting in Changes the change to first-level DSA case. 2) replace first paragraph of 5.1.2 with: The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server does not master or shadow any information (e.g. it is an LDAP gateway to a public X.500 directory) this attribute will be absent. This attribute allows a client to choose suitable base objects for searching when it has contacted a server. and then noting that listing "" as a value of namingContexts has been deprecated in Appendix A. Comments? Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 16:00:45 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07320 for ; Tue, 28 Jan 2003 16:00:43 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SL37AQ066104; Tue, 28 Jan 2003 21:03:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SKw8MJ065969; Tue, 28 Jan 2003 20:58:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 20:58:08 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SKw4AM065952 for ; Tue, 28 Jan 2003 20:58:04 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Jan 2003 13:56:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 28 Jan 2003 13:57:28 -0700 From: "Jim Sermersheim" To: Subject: Re: Models: Subclassing Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit That's what I suspected. We should just make sure that: 1) there aren't valid uses of performing these types of subclassing (especially that are in use today) 2) we attempt to coordinate this clarification with the X.500 people (at least raise this to their attention) Jim >>> "Kurt D. Zeilenga" 1/28/03 12:06:59 PM >>> At 11:22 AM 1/27/2003, Jim Sermersheim wrote: >Section 2.4 describes object class subclassing, but should express the >effect of subclassing (namely that a subclass inherits the MUST and MAY >list(s) of superior object classes in its superclass chain, but does not >inherit Name Forms or DIT Content Rules) > >Section 2.4.2 states "Structural object classes cannot subclass >auxiliary object classes." and Section 2.4.3 states "Auxiliary object >classes cannot subclass structural object classes.". I can't find these >restrictions in X.501--can you point out the reference? You won't find any clear, explicit statement in X.501 regarding this. I added the above statements to address what I consider to be a technical omission in the existing specification. The alternative would be describe the semantics of such subclassing. I didn't take this alternative as such subclassing makes no sense to me. Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 16:10:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07662 for ; Tue, 28 Jan 2003 16:10:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SLD7AQ066512; Tue, 28 Jan 2003 21:13:11 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SL4TOB066151; Tue, 28 Jan 2003 21:04:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 21:04:29 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SL4LAM066121; Tue, 28 Jan 2003 21:04:22 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Jan 2003 14:02:26 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 28 Jan 2003 14:03:46 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: Models: Naming Contexts Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I prefer #1 as there is/are server(s) that already do this today. I also note that the reason given for the attribute (This attribute allows a client to choose suitable base objects for searching when it has contacted a server.) is well aligned with the notion of advertising the DIT root ("") when the server is a first-level DSA. This reconciles this advertisement attribute with the fact that X.511 allows a search to be based at the tree root. Jim >>> "Kurt D. Zeilenga" 1/28/03 1:24:12 PM >>> At 10:17 AM 1/27/2003, Jim Sermersheim wrote: >>From Models 05 > >>5.1.2. 'namingContexts' > >> If the server believes it masters or shadows the entire >> directory, the attribute will have a single value, and that value >will >> be the empty string (indicating the null DN of the root). > >What if the server is a first level DSA which masters the root of the >DIT, and also one or more other naming contexts? Well, this sentence wouldn't apply in this case. So, taking the specification literally, the namingContext attribute would have one value for each naming contexts it masters or shadows, the context prefix of the naming context. This would NOT include "" as "" is not a valid context prefix. >I believe this is a flaw and should be corrected to allow the >namingContexts attribute to hold values in addition to the empty >string. Please refer to X.501 Section 18.5 I have a couple of alternatives approaches which could be taken 1) replace first paragraph of 5.1.2 with: The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server is a first-level DSA [X.501], it should list (in addition) an empty string (indicating the root of the DIT). If the server does not master or shadow any information (e.g. it is an LDAP gateway to a public X.500 directory) this attribute will be absent. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string (indicating the root of the DIT). This attribute allows a client to choose suitable base objects for searching when it has contacted a server. and then noting in Changes the change to first-level DSA case. 2) replace first paragraph of 5.1.2 with: The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server does not master or shadow any information (e.g. it is an LDAP gateway to a public X.500 directory) this attribute will be absent. This attribute allows a client to choose suitable base objects for searching when it has contacted a server. and then noting that listing "" as a value of namingContexts has been deprecated in Appendix A. Comments? Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Jan 28 16:41:34 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08857 for ; Tue, 28 Jan 2003 16:41:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SLh7AQ067764; Tue, 28 Jan 2003 21:43:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0SLfxBH067716; Tue, 28 Jan 2003 21:41:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 28 Jan 2003 21:41:59 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0SLftAM067703 for ; Tue, 28 Jan 2003 21:41:55 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Jan 2003 14:39:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 28 Jan 2003 14:41:19 -0700 From: "Jim Sermersheim" To: , Subject: RE: Models: Naming Contexts Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think what it boils down to is, once the user has determined that the root can be searched, it can perform a *single* search operation, and use referral handling if it wants to progress the operation through the entire tree. Jim >>> Christopher Oliva 1/28/03 11:10:10 AM >>> A couple of comments on this: - the suggestion would allow the client to recognize a server as a first level DSA but I'm not sure where this term is defined in the specs and if the requirements for claiming that role have been established. It's defined in X.501 as not allowing a superior reference and holding a complete list of references to naming contexts below the root. - I'm not sure what a client will gain by detecting the root in the namingContexts attribute (according to the new proposal). Because, a server might still have references to naming contexts it doesn't master or shadow. I suppose this will tell the client to stop its search after querying a first level DSA and receiving an "entry not found" error. Otherwise the client could continue its search to another server (to which it has acquired a reference). Perhaps this client behaviour should be documented - although I'm not sure how many existing clients would conform to that. Chris. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Monday, January 27, 2003 3:02 PM To: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Naming Contexts I'm going to flip flop on this one more time--I'm back to my original assertion. Imagine a server that holds [dc=com] [dc=novell,dc=com] [dc=ibm,dc=com] (subordinate reference) [dc=org] (subordinate reference) and [dc=net] (subordinate reference). The server is a first level DSA. I want to know that it masters the root of the tree, regardless of the fact that it has subordinate references directly below the root. I want to be able to search from the root of the tree and receive the search result references for the subref's, intermixed with the search results in the dc=novell,dc=com subtree. Jim >>> John McMeeking 1/27/03 12:19:27 PM >>> > >Jim Sermersheim wrote: > >>From Models 05 >> >>>5.1.2. 'namingContexts' > >>> If the server believes it masters or shadows the entire >>> directory, the attribute will have a single value, and that value >will >>> be the empty string (indicating the null DN of the root). >> >>What if the server is a first level DSA which masters the root of the >>DIT, and also one or more other naming contexts? >>I believe this is a flaw and should be corrected to allow the >>namingContexts attribute to hold values in addition to the empty >>string. > >I'm having a hard time with the notion of mastering the root of the DIT >and some other subtree. Would that be something like: > namingContexts: > namingContexts: o=my company,c=us >??? Yes, this could happen if it mastered the root as well as o=my company,c=us, but not c=us (it would likely have a subordinate reference to c=us). >If you then create the entry "c=us", would "o=my company,c=us" still be >listed as a namingcontext? If o=my company has no siblings that are mastered elsewhere, I would think that c=us would suffice. But if there are subordinate references under c=us, I would expect to see both values. >Since "" is not the root of a DIT subtree, perhaps it would be more >appropriate for such servers to return the root entries of subtrees >actually present on the server. As new subtrees are created, the >namingContexts attribute would be updated accordingly. Why is "" not the root of a DIT? If I perform a subtree search where the base is "", I am asking to search the entire DIT. See Section 10.2.2 of X.511 (especially "or possibly the root"). I want to know *when* I can search from the DIT root, and I also want to know which contiguous naming contexts a server holds. That said, I do think there's a problem with my original request: A naming context is defined to be a subtree. A server either masters the entire DIT or it doesn't. If a server doesn't master the entire DIT, the empty name cannot be advertised. If a server does master the entire DIT, there shouldn't be namingContexts subordinate to the root. I was mistakenly mixing up my notion of "areas of replication" with namingContexts. I will re-state what I think the real problem is in another mail. >I'm trying to think of cases where it would be necessary for the server >to advertise that "c=au" could be added to the directory, but doesn't >yet exist. It seems more useful in this scenario to only list the subtrees >that have been created. If the server only holds the subtree "o=my >company, >c=us" I'd still expect that to be present in the namingcontexts attribute >even if the entry doesn't exist. I'm getting stuck on a couple things: first, there's no way to advertise names that "could be added". I think you're trying to say that there's an implicit advertisement for this, but I'm not seeing it. Next I don't believe values of the namingContexts attribute should point to non-existent entries in the local DIB fragment. I think I'm missing what you're saying though. >John McMeeking Jim From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 29 12:53:06 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24544 for ; Wed, 29 Jan 2003 12:53:05 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0THr8AQ039781; Wed, 29 Jan 2003 17:53:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0THnDnN039636; Wed, 29 Jan 2003 17:49:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 29 Jan 2003 17:49:13 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0THnAAM039626 for ; Wed, 29 Jan 2003 17:49:11 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18dwKh-0003WG-00; Wed, 29 Jan 2003 18:49:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18dwKg-0001c1-00; Wed, 29 Jan 2003 18:49:06 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Models: aliases Date: Wed, 29 Jan 2003 18:49:06 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Is this a correct alias entry: dn: o=foo objectclass: alias aliasedObjectName: o=bar or should it also contain the attribute o: foo ? If the original entry is correct, it violates 2.2.1 in [Models]: These AVAs [in the RDN] are chosen from the attributes of the entry. If "o: foo" should be added, it violates the description of the 'alias' object class (2.6.1), which does not allow attribute 'o'. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Jan 29 14:14:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26696 for ; Wed, 29 Jan 2003 14:14:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0TJD9AS043963; Wed, 29 Jan 2003 19:16:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0TJ4l7d043539; Wed, 29 Jan 2003 19:04:47 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 29 Jan 2003 19:04:47 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0TJ4jAM043528 for ; Wed, 29 Jan 2003 19:04:45 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0TJ4Z8O077336; Wed, 29 Jan 2003 19:04:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Jan 2003 11:03:09 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: aliases Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 09:49 AM 1/29/2003, Hallvard B Furuseth wrote: >Is this a correct alias entry: > dn: o=foo > objectclass: alias > aliasedObjectName: o=bar >or should it also contain the attribute > o: foo >? yes. And you need another objectClass. >If the original entry is correct, it violates 2.2.1 in [Models]: > These AVAs [in the RDN] are chosen from the attributes of the > entry. Not the case. >If "o: foo" should be added, it violates the description of the >'alias' object class (2.6.1), which does not allow attribute 'o'. You need to add extensibleObject, an objectClass which SUPs alias and allows o, or adjust your DIT content rules to allow o in alias entries. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 12:52:03 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05454 for ; Thu, 30 Jan 2003 12:52:02 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UHrBAQ019134; Thu, 30 Jan 2003 17:54:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UHln0U018592; Thu, 30 Jan 2003 17:47:49 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 17:47:49 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UHlhAM018550 for ; Thu, 30 Jan 2003 17:47:43 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 30 Jan 2003 10:45:46 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 30 Jan 2003 10:47:06 -0700 From: "Jim Sermersheim" To: , Subject: Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-models-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >The Last Call period will end on Friday, January 30, 2003. Is that Fri, Jan 31, or Thu Jan 30? Please say the 31st Jim >>> "RL 'Bob' Morgan" 1/14/03 1:09:08 AM >>> This message initiates an LDAPbis Working Group Last Call on the document: LDAP: Directory Information Models 16 December 2002 The purpose of this WG Last Call it to ensure that the Working Group has achieved consensus that the document is suitable for publication as an IETF Draft Standard. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor, Kurt Zeilenga, kurt@OpenLDAP.org. The Last Call period will end on Friday, January 30, 2003. Upon completion of the Last Call, the WG chair(s) will take action based upon the consensus of the WG. Possible actions include: 1) recommending to the IETF Application Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as a Draft Standard (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! - RL "Bob" Morgan LDAPbis co-chair From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 14:44:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08680 for ; Thu, 30 Jan 2003 14:44:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UJhCAm032465; Thu, 30 Jan 2003 19:47:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UJUx2P027844; Thu, 30 Jan 2003 19:30:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 19:30:59 +0000 Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UJUsAM027776 for ; Thu, 30 Jan 2003 19:30:54 GMT (envelope-from Chris.Oliva@entrust.com) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 30 Jan 2003 14:30:27 -0500 Message-ID: From: Christopher Oliva To: ietf-ldapbis@OpenLDAP.org Subject: Models: preservation of user information Date: Thu, 30 Jan 2003 14:30:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C896.09650460" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C896.09650460 Content-Type: text/plain; charset="iso-8859-1" Section 6.1 includes this paragraph: Where such requirements have not be explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned. This would allow the server to return values that are not identical to the original values added by an application. Partly because sometimes, equality rules only determine equivalency instead of exact equality. I think this could lead to problems. For instance, name information for attributes with a caseIgnoreMatch equality matching rule might be returned in the wrong case which would actually be a loss of information for the application. I would prefer mandating servers to return the exact value that was originally added (when there are no explicit constraints in the schema definition for that item). Essentially this would be changing the above paragraph to: Where such requirements have not been explicitly stated, servers MUST preserve the value of user information (return the same values that were originally added). Chris. ------_=_NextPart_001_01C2C896.09650460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Models: preservation of user information

Section 6.1 includes this paragraph:

  Where such requirements have not be explicitly = stated, servers SHOULD
  preserve the value of user information but = MAY return the value in a
  different form.  And where a server is = unable (or unwilling) to
  preserve the value of user information, the = server SHALL ensure that
  an equivalent value (per Section 2.3) is = returned.

This would allow the server to return values that are = not identical to the original values added by an application. Partly = because sometimes, equality rules only determine equivalency instead of = exact equality.

I think this could lead to problems. For instance, = name information for attributes with a caseIgnoreMatch equality = matching rule might be returned in the wrong case which would actually = be a loss of information for the application.

I would prefer mandating servers to return the exact = value that was originally added (when there are no explicit constraints = in the schema definition for that item). Essentially this would be = changing the above paragraph to:

  Where such requirements have not been = explicitly stated, servers MUST
  preserve the value of user information = (return the same values that
  were originally added).

Chris.

------_=_NextPart_001_01C2C896.09650460-- From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 16:57:35 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11582 for ; Thu, 30 Jan 2003 16:57:34 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0ULrBAq079072; Thu, 30 Jan 2003 22:00:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0ULmrCF076576; Thu, 30 Jan 2003 21:48:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 21:48:53 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0ULmiAM076395; Thu, 30 Jan 2003 21:48:45 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18eMY4-0000Ep-00; Thu, 30 Jan 2003 22:48:40 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eMY4-0005U5-00; Thu, 30 Jan 2003 22:48:40 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: aliases In-Reply-To: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> References: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 30 Jan 2003 22:48:40 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: > You need to add extensibleObject, an objectClass > which SUPs alias and allows o, I don't like this: I never needed to do any of this before - neither with ISODE (X.500) nor OpenLDAP. It seems rather heavy to force people to get their own OID and make new object classes just in order to use aliases, if extensibleObject is not supported on their server. > or adjust your DIT > content rules to allow o in alias entries. That's not too widely supported yet either, is it? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 17:10:31 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11793 for ; Thu, 30 Jan 2003 17:10:31 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UMDDAO086336; Thu, 30 Jan 2003 22:13:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UM9o9b086115; Thu, 30 Jan 2003 22:09:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 22:09:50 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UM9kAM086036 for ; Thu, 30 Jan 2003 22:09:46 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18eMsQ-0000K4-00; Thu, 30 Jan 2003 23:09:42 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eMsP-0005X1-00; Thu, 30 Jan 2003 23:09:41 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: models: unnecessary numericoids Date: Thu, 30 Jan 2003 23:09:41 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Suggestion: The s in [Models] 4.1.4 (MatchingRuleUseDescription) and 4.1.6 (DITContentRuleDescription) could be plain s, the schema knows their names. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 17:30:31 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12172 for ; Thu, 30 Jan 2003 17:30:30 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UMXDAQ092731; Thu, 30 Jan 2003 22:33:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UMU2Xo091596; Thu, 30 Jan 2003 22:30:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 22:30:01 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UMTvAM091552 for ; Thu, 30 Jan 2003 22:29:58 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 30 Jan 2003 15:28:01 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 30 Jan 2003 15:29:16 -0700 From: "Jim Sermersheim" To: Subject: Re: Models: aliases Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h0UMTwAM091566 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit What does the statement in Section 12.3.3 of X.501 mean? "Note * The object class alias does not specify appropriate attribte types for the RDN of an alias entry. Administrative Authorities may specify subclasses of the class alias which specify useful attribute types for RDNs of alias entris". To me, it means that with X.500 directories, you have to subclass the objectclass. LDAP goes one better by defining the extensibleObject class. Some directories however, do not follow the rules to the letter. It sounds like those that you've tested make an exception. Novell's adopts the rules set up in the target object. Jim >>> Hallvard B Furuseth 1/30/03 2:48:40 PM >>> Kurt D. Zeilenga writes: > You need to add extensibleObject, an objectClass > which SUPs alias and allows o, I don't like this: I never needed to do any of this before - neither with ISODE (X.500) nor OpenLDAP. It seems rather heavy to force people to get their own OID and make new object classes just in order to use aliases, if extensibleObject is not supported on their server. > or adjust your DIT > content rules to allow o in alias entries. That's not too widely supported yet either, is it? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 17:30:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12175 for ; Thu, 30 Jan 2003 17:30:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UMXDAS092731; Thu, 30 Jan 2003 22:33:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UMPo4w091396; Thu, 30 Jan 2003 22:25:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 22:25:50 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UMPkAM091387 for ; Thu, 30 Jan 2003 22:25:46 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0UMPb8O004991; Thu, 30 Jan 2003 22:25:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030130141306.019f77e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 30 Jan 2003 14:24:11 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: aliases Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 01:48 PM 1/30/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> You need to add extensibleObject, an objectClass >> which SUPs alias and allows o, > >I don't like this: Well, there's lots in LDAP/X.500 I don't like... but this alone is not good reason to change the specification. >I never needed to do any of this before - neither with ISODE (X.500) In X.500, the practice (as I understand it) was to subclass 'alias' as needed. >nor OpenLDAP. OpenLDAP release code doesn't verify that the AVAs of the RDN exist in any case. It's a bug whose fix is coming soon. >It seems rather heavy to force people to get their >own OID and make new object classes just in order >to use aliases, if extensibleObject is not supported >on their server. Some could publish a "Common subclasses of 'alias'" technical specification.... >> or adjust your DIT >> content rules to allow o in alias entries. > >That's not too widely supported yet either, is it? Not in too many LDAP-only servers (at least one does)... but, from what I gather, a number of LDAP/DAP servers do support it. From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 17:44:50 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12428 for ; Thu, 30 Jan 2003 17:44:49 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UMhDAc096682; Thu, 30 Jan 2003 22:46:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UMYLoO093416; Thu, 30 Jan 2003 22:34:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 22:34:21 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UMYGAM093325 for ; Thu, 30 Jan 2003 22:34:17 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18eNG9-0002ZX-00; Thu, 30 Jan 2003 23:34:13 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eNG9-0005bZ-00; Thu, 30 Jan 2003 23:34:13 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Models: Matching Rule Uses Date: Thu, 30 Jan 2003 23:34:13 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Models] says: > 4.1.4. Matching Rule Uses > > A matching rule use lists the attributes which are suitable for use > with an extensible matching rule Please add something like "(in addition to those uses expressed in AttributeType descriptions)". BTW, how do Matching Rule Uses relate to the statements in [Syntaxes] about which matching rules can be used with which syntaxes? For example, [Syntaxes] 5.2.6 says: > The caseIgnoreMatch rule compares an assertion value of the Directory > String syntax to an attribute value of a syntax (e.g. the Directory > String, Printable String, Country String or Telephone Number syntax) > whose corresponding ASN.1 type is DirectoryString or one of its > alternative string types, e.g. PrintableString. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 18:27:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13227 for ; Thu, 30 Jan 2003 18:27:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNNEAk010665; Thu, 30 Jan 2003 23:30:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UNJPPc008490; Thu, 30 Jan 2003 23:19:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 23:19:25 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNJKAM008415 for ; Thu, 30 Jan 2003 23:19:21 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Models: preservation of user information Date: Fri, 31 Jan 2003 10:19:24 +1100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C8B6.070DC060" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Models: preservation of user information Thread-Index: AcLImGorAUoY0a5VQsGqrSyfimdv+AAHTRTQ From: "Ramsay, Ron" To: "Christopher Oliva" , Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C8B6.070DC060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You should store the information in an attribute whose matching rule is = caseExactMatch. The meaning of using caseIgnoreMatch is that case is not = important. -----Original Message----- From: Christopher Oliva [mailto:Chris.Oliva@entrust.com] Sent: Friday, 31 January 2003 06:30 To: ietf-ldapbis@OpenLDAP.org Subject: Models: preservation of user information Section 6.1 includes this paragraph:=20 Where such requirements have not be explicitly stated, servers SHOULD=20 preserve the value of user information but MAY return the value in a=20 different form. And where a server is unable (or unwilling) to=20 preserve the value of user information, the server SHALL ensure that=20 an equivalent value (per Section 2.3) is returned.=20 This would allow the server to return values that are not identical to = the original values added by an application. Partly because sometimes, = equality rules only determine equivalency instead of exact equality. I think this could lead to problems. For instance, name information for = attributes with a caseIgnoreMatch equality matching rule might be = returned in the wrong case which would actually be a loss of information = for the application. I would prefer mandating servers to return the exact value that was = originally added (when there are no explicit constraints in the schema = definition for that item). Essentially this would be changing the above = paragraph to: Where such requirements have not been explicitly stated, servers MUST=20 preserve the value of user information (return the same values that=20 were originally added).=20 Chris.=20 ------_=_NextPart_001_01C2C8B6.070DC060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Models: preservation of user information
You=20 should store the information in an attribute whose matching rule is=20 caseExactMatch. The meaning of using caseIgnoreMatch is that case is not = important.
-----Original Message-----
From: Christopher Oliva=20 [mailto:Chris.Oliva@entrust.com]
Sent: Friday, 31 January = 2003=20 06:30
To: ietf-ldapbis@OpenLDAP.org
Subject: = Models:=20 preservation of user information


Section 6.1 includes this paragraph:

  Where such requirements have not be = explicitly stated,=20 servers SHOULD
  preserve the value of = user=20 information but MAY return the value in a
 =20 different form.  And where a server is unable (or unwilling) = to=20
  preserve the value of user information, the = server=20 SHALL ensure that
  an equivalent value = (per=20 Section 2.3) is returned.

This would allow the server to return values that = are not=20 identical to the original values added by an application. Partly = because=20 sometimes, equality rules only determine equivalency instead of exact=20 equality.

I think this could lead to problems. For instance, = name=20 information for attributes with a caseIgnoreMatch equality matching = rule might=20 be returned in the wrong case which would actually be a loss of = information=20 for the application.

I would prefer mandating servers to return the exact = value=20 that was originally added (when there are no explicit constraints in = the=20 schema definition for that item). Essentially this would be changing = the above=20 paragraph to:

  Where such requirements have not been = explicitly=20 stated, servers MUST
  preserve the = value of user=20 information (return the same values that
  were=20 originally added).

Chris.

------_=_NextPart_001_01C2C8B6.070DC060-- From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 18:28:57 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13273 for ; Thu, 30 Jan 2003 18:28:56 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNDBAm007483; Thu, 30 Jan 2003 23:31:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UN3Mhe002400; Thu, 30 Jan 2003 23:03:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 23:03:22 +0000 Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UN3IAM002376 for ; Thu, 30 Jan 2003 23:03:18 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h0UN3Hq6022006 for ; Thu, 30 Jan 2003 15:03:17 -0800 Received: from D-128-208-197-49.dhcp4.washington.edu (D-128-208-197-49.dhcp4.washington.edu [128.208.197.49]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h0UN3Hup022044 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 30 Jan 2003 15:03:17 -0800 Date: Thu, 30 Jan 2003 15:03:40 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: IETF ldapbis WG Subject: Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-models-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: On Tue, 14 Jan 2003, RL 'Bob' Morgan wrote: > The Last Call period will end on Friday, January 30, 2003. I did indeed mean Friday January 31. Given the many comments in progress, I'll formally extend the Last Call to Friday February 7. So keep 'em coming. - RL "Bob" --- > This message initiates an LDAPbis Working Group Last Call on the > document: > > LDAP: Directory Information Models > > 16 December 2002 > > The purpose of this WG Last Call it to ensure that the Working Group > has achieved consensus that the document is suitable for publication > as an IETF Draft Standard. > > Please review the document for both technical and editorial problems. > Technical issues should be discussed on this list. Editorial issues > may be sent to the document editor, Kurt Zeilenga, kurt@OpenLDAP.org. > > The Last Call period will end on Friday, January 30, 2003. > > Upon completion of the Last Call, the WG chair(s) will take action > based upon the consensus of the WG. Possible actions include: > > 1) recommending to the IETF Application Area Directors that the > document, after possible editorial or other minor changes, be > considered by the IESG for publication as a Draft Standard > (which generally involves an IETF-wide Last Call); or > > 2) requiring that outstanding issues be adequately addressed prior > to further action (including, possibly, another Last Call). > > Remember that it is our responsibility as Working Group members to > ensure the quality of our documents and of the Internet Standards > process. So, please read and comment! > > - RL "Bob" Morgan > LDAPbis co-chair From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 18:56:53 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13765 for ; Thu, 30 Jan 2003 18:56:52 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNXBB4013622; Thu, 30 Jan 2003 23:59:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UNOQpS011317; Thu, 30 Jan 2003 23:24:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 23:24:26 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNOMAM011196 for ; Thu, 30 Jan 2003 23:24:22 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Models: aliases Date: Fri, 31 Jan 2003 10:24:27 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Models: aliases X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Index: AcLIqwG+RjRwU3jrQ7K4JBaQq5XLTwAC1Qsw From: "Ramsay, Ron" To: "Hallvard B Furuseth" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h0UNONAM011290 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think the appropriate way is to subclass an alias object with the required naming attribute. This also requires a new object class. At least it doesn't change the underlying model and it doesn't use an object without definition. Ron. -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Friday, 31 January 2003 08:49 To: Kurt D. Zeilenga Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: aliases Kurt D. Zeilenga writes: > You need to add extensibleObject, an objectClass > which SUPs alias and allows o, I don't like this: I never needed to do any of this before - neither with ISODE (X.500) nor OpenLDAP. It seems rather heavy to force people to get their own OID and make new object classes just in order to use aliases, if extensibleObject is not supported on their server. > or adjust your DIT > content rules to allow o in alias entries. That's not too widely supported yet either, is it? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 18:56:57 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13774 for ; Thu, 30 Jan 2003 18:56:56 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNXBB2013622; Thu, 30 Jan 2003 23:59:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UNRx5Z013123; Thu, 30 Jan 2003 23:27:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 23:27:59 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNRsAM013028 for ; Thu, 30 Jan 2003 23:27:55 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Models: aliases Date: Fri, 31 Jan 2003 10:27:43 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Models: aliases Thread-Index: AcLIr++LBFHc0jL2QwGnp0WgXSMt9AABuxgg From: "Ramsay, Ron" To: "Jim Sermersheim" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h0UNRtAM013113 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I believe the only X.500 conformant way of using aliases is to subclass alias objects which contain the required naming attribute. Ron. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 31 January 2003 09:29 To: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: aliases What does the statement in Section 12.3.3 of X.501 mean? "Note * The object class alias does not specify appropriate attribte types for the RDN of an alias entry. Administrative Authorities may specify subclasses of the class alias which specify useful attribute types for RDNs of alias entris". To me, it means that with X.500 directories, you have to subclass the objectclass. LDAP goes one better by defining the extensibleObject class. Some directories however, do not follow the rules to the letter. It sounds like those that you've tested make an exception. Novell's adopts the rules set up in the target object. Jim >>> Hallvard B Furuseth 1/30/03 2:48:40 PM >>> Kurt D. Zeilenga writes: > You need to add extensibleObject, an objectClass > which SUPs alias and allows o, I don't like this: I never needed to do any of this before - neither with ISODE (X.500) nor OpenLDAP. It seems rather heavy to force people to get their own OID and make new object classes just in order to use aliases, if extensibleObject is not supported on their server. > or adjust your DIT > content rules to allow o in alias entries. That's not too widely supported yet either, is it? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 18:56:56 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13770 for ; Thu, 30 Jan 2003 18:56:55 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNXBB6013622; Thu, 30 Jan 2003 23:59:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UNUxkR013434; Thu, 30 Jan 2003 23:30:59 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 23:30:59 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNUsAM013388 for ; Thu, 30 Jan 2003 23:30:55 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Models: Matching Rule Uses Date: Fri, 31 Jan 2003 10:30:59 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Models: Matching Rule Uses Thread-Index: AcLIsXr4hCIyKMn7SbGw4X8paH4H5AABgrLg From: "Ramsay, Ron" To: "Hallvard B Furuseth" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h0UNUtAM013402 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit caseIgnoreMatch is not an *extensible* matching rule. -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Friday, 31 January 2003 09:34 To: ietf-ldapbis@OpenLDAP.org Subject: Models: Matching Rule Uses [Models] says: > 4.1.4. Matching Rule Uses > > A matching rule use lists the attributes which are suitable for use > with an extensible matching rule Please add something like "(in addition to those uses expressed in AttributeType descriptions)". BTW, how do Matching Rule Uses relate to the statements in [Syntaxes] about which matching rules can be used with which syntaxes? For example, [Syntaxes] 5.2.6 says: > The caseIgnoreMatch rule compares an assertion value of the Directory > String syntax to an attribute value of a syntax (e.g. the Directory > String, Printable String, Country String or Telephone Number syntax) > whose corresponding ASN.1 type is DirectoryString or one of its > alternative string types, e.g. PrintableString. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 19:31:47 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14406 for ; Thu, 30 Jan 2003 19:31:45 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V03CAq025014; Fri, 31 Jan 2003 00:34:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0UNhcPM019018; Thu, 30 Jan 2003 23:43:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 30 Jan 2003 23:43:38 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0UNhYAM018947 for ; Thu, 30 Jan 2003 23:43:34 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 30 Jan 2003 16:41:37 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 30 Jan 2003 16:42:55 -0700 From: "Jim Sermersheim" To: , Subject: Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-models-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Oh good, so I can wait until Feb 6th to begin looking at it again :-) >>> "RL 'Bob' Morgan" 1/30/03 4:03:40 PM >>> On Tue, 14 Jan 2003, RL 'Bob' Morgan wrote: > The Last Call period will end on Friday, January 30, 2003. I did indeed mean Friday January 31. Given the many comments in progress, I'll formally extend the Last Call to Friday February 7. So keep 'em coming. - RL "Bob" --- > This message initiates an LDAPbis Working Group Last Call on the > document: > > LDAP: Directory Information Models > > 16 December 2002 > > The purpose of this WG Last Call it to ensure that the Working Group > has achieved consensus that the document is suitable for publication > as an IETF Draft Standard. > > Please review the document for both technical and editorial problems. > Technical issues should be discussed on this list. Editorial issues > may be sent to the document editor, Kurt Zeilenga, kurt@OpenLDAP.org. > > The Last Call period will end on Friday, January 30, 2003. > > Upon completion of the Last Call, the WG chair(s) will take action > based upon the consensus of the WG. Possible actions include: > > 1) recommending to the IETF Application Area Directors that the > document, after possible editorial or other minor changes, be > considered by the IESG for publication as a Draft Standard > (which generally involves an IETF-wide Last Call); or > > 2) requiring that outstanding issues be adequately addressed prior > to further action (including, possibly, another Last Call). > > Remember that it is our responsibility as Working Group members to > ensure the quality of our documents and of the Internet Standards > process. So, please read and comment! > > - RL "Bob" Morgan > LDAPbis co-chair From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 19:36:15 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14529 for ; Thu, 30 Jan 2003 19:36:14 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V0NEAo033494; Fri, 31 Jan 2003 00:39:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V0Lffq032594; Fri, 31 Jan 2003 00:21:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 00:21:41 +0000 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V0LbAM032439 for ; Fri, 31 Jan 2003 00:21:37 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 30 Jan 2003 17:19:50 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 30 Jan 2003 17:21:03 -0700 From: "Jim Sermersheim" To: , , Subject: RE: Models: Matching Rule Uses Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Why not? I may have an attribute who's syntax is caseExactMatch. I may want to search for values of that attribute using an extensible match filter where the rule is caseIgnoreMatch. Jim >>> "Ramsay, Ron" 1/30/03 4:30:59 PM >>> caseIgnoreMatch is not an *extensible* matching rule. -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Friday, 31 January 2003 09:34 To: ietf-ldapbis@OpenLDAP.org Subject: Models: Matching Rule Uses [Models] says: > 4.1.4. Matching Rule Uses > > A matching rule use lists the attributes which are suitable for use > with an extensible matching rule Please add something like "(in addition to those uses expressed in AttributeType descriptions)". BTW, how do Matching Rule Uses relate to the statements in [Syntaxes] about which matching rules can be used with which syntaxes? For example, [Syntaxes] 5.2.6 says: > The caseIgnoreMatch rule compares an assertion value of the Directory > String syntax to an attribute value of a syntax (e.g. the Directory > String, Printable String, Country String or Telephone Number syntax) > whose corresponding ASN.1 type is DirectoryString or one of its > alternative string types, e.g. PrintableString. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 19:56:48 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15068 for ; Thu, 30 Jan 2003 19:56:47 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V0rBAi044339; Fri, 31 Jan 2003 00:59:34 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V0qjIB044039; Fri, 31 Jan 2003 00:52:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 00:52:45 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V0qeAM043856 for ; Fri, 31 Jan 2003 00:52:41 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Models: Matching Rule Uses Date: Fri, 31 Jan 2003 11:52:37 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Models: Matching Rule Uses Thread-Index: AcLIvrOHLjAQntI8Rz+5fLGdGjZl2gAAzk9g From: "Ramsay, Ron" To: "Jim Sermersheim" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h0V0qgAM043987 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I should think the normal use of a matching rule is in the 'equalityMatch' choice of the filter. I also think 'extensibleMatch' is an attempt to create a new semantic and that the paragraphs below provide the means to scope this new meaning. The use of the matching rule in an attribute definition is automatically scoped. Ron. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Friday, 31 January 2003 11:21 To: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org; h.b.furuseth@usit.uio.no Subject: RE: Models: Matching Rule Uses Why not? I may have an attribute who's syntax is caseExactMatch. I may want to search for values of that attribute using an extensible match filter where the rule is caseIgnoreMatch. Jim >>> "Ramsay, Ron" 1/30/03 4:30:59 PM >>> caseIgnoreMatch is not an *extensible* matching rule. -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Friday, 31 January 2003 09:34 To: ietf-ldapbis@OpenLDAP.org Subject: Models: Matching Rule Uses [Models] says: > 4.1.4. Matching Rule Uses > > A matching rule use lists the attributes which are suitable for use > with an extensible matching rule Please add something like "(in addition to those uses expressed in AttributeType descriptions)". BTW, how do Matching Rule Uses relate to the statements in [Syntaxes] about which matching rules can be used with which syntaxes? For example, [Syntaxes] 5.2.6 says: > The caseIgnoreMatch rule compares an assertion value of the Directory > String syntax to an attribute value of a syntax (e.g. the Directory > String, Printable String, Country String or Telephone Number syntax) > whose corresponding ASN.1 type is DirectoryString or one of its > alternative string types, e.g. PrintableString. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 19:57:03 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15095 for ; Thu, 30 Jan 2003 19:57:02 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V0rBAg044339; Fri, 31 Jan 2003 00:59:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V0g394041179; Fri, 31 Jan 2003 00:42:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 00:42:03 +0000 Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V0fwAM040826 for ; Fri, 31 Jan 2003 00:41:59 GMT (envelope-from Chris.Oliva@entrust.com) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 30 Jan 2003 19:41:33 -0500 Message-ID: From: Christopher Oliva To: "'Ramsay, Ron'" , ietf-ldapbis@OpenLDAP.org Subject: RE: Models: preservation of user information Date: Thu, 30 Jan 2003 19:41:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C8C1.7C4DC4F0" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C8C1.7C4DC4F0 Content-Type: text/plain; charset="iso-8859-1" It means it's not important for matching values. When I retrieve values from the directory, I expect to get the same values I entered since I am not asking the directory to evaluate an equality assertion. Although upper and lower case may be equivalent, the meaning is not always the same to applications or users. Many standard attributes are already defined with caseIgnoreMatch and can't be changed to caseExactMatch without breaking existing clients that expect to search using the caseIgnoreMatch matching rule. Chris. -----Original Message----- From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] Sent: Thursday, January 30, 2003 6:19 PM To: Christopher Oliva; ietf-ldapbis@OpenLDAP.org Subject: RE: Models: preservation of user information You should store the information in an attribute whose matching rule is caseExactMatch. The meaning of using caseIgnoreMatch is that case is not important. -----Original Message----- From: Christopher Oliva [mailto:Chris.Oliva@entrust.com] Sent: Friday, 31 January 2003 06:30 To: ietf-ldapbis@OpenLDAP.org Subject: Models: preservation of user information Section 6.1 includes this paragraph: Where such requirements have not be explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned. This would allow the server to return values that are not identical to the original values added by an application. Partly because sometimes, equality rules only determine equivalency instead of exact equality. I think this could lead to problems. For instance, name information for attributes with a caseIgnoreMatch equality matching rule might be returned in the wrong case which would actually be a loss of information for the application. I would prefer mandating servers to return the exact value that was originally added (when there are no explicit constraints in the schema definition for that item). Essentially this would be changing the above paragraph to: Where such requirements have not been explicitly stated, servers MUST preserve the value of user information (return the same values that were originally added). Chris. ------_=_NextPart_001_01C2C8C1.7C4DC4F0 Content-Type: text/html; charset="iso-8859-1" Models: preservation of user information
It means it's not important for matching values. When I retrieve values from the directory, I expect to get the same values I entered since I am not asking the directory to evaluate an equality assertion. Although upper and lower case may be equivalent, the meaning is not always the same to applications or users.
 
Many standard attributes are already defined with caseIgnoreMatch and can't be changed to caseExactMatch without breaking existing clients that expect to search using the caseIgnoreMatch matching rule.
 
Chris.
-----Original Message-----
From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
Sent: Thursday, January 30, 2003 6:19 PM
To: Christopher Oliva; ietf-ldapbis@OpenLDAP.org
Subject: RE: Models: preservation of user information

You should store the information in an attribute whose matching rule is caseExactMatch. The meaning of using caseIgnoreMatch is that case is not important.
-----Original Message-----
From: Christopher Oliva [mailto:Chris.Oliva@entrust.com]
Sent: Friday, 31 January 2003 06:30
To: ietf-ldapbis@OpenLDAP.org
Subject: Models: preservation of user information


Section 6.1 includes this paragraph:

  Where such requirements have not be explicitly stated, servers SHOULD
  preserve the value of user information but MAY return the value in a
  different form.  And where a server is unable (or unwilling) to
  preserve the value of user information, the server SHALL ensure that
  an equivalent value (per Section 2.3) is returned.

This would allow the server to return values that are not identical to the original values added by an application. Partly because sometimes, equality rules only determine equivalency instead of exact equality.

I think this could lead to problems. For instance, name information for attributes with a caseIgnoreMatch equality matching rule might be returned in the wrong case which would actually be a loss of information for the application.

I would prefer mandating servers to return the exact value that was originally added (when there are no explicit constraints in the schema definition for that item). Essentially this would be changing the above paragraph to:

  Where such requirements have not been explicitly stated, servers MUST
  preserve the value of user information (return the same values that
  were originally added).

Chris.

------_=_NextPart_001_01C2C8C1.7C4DC4F0-- From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 20:01:05 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15221 for ; Thu, 30 Jan 2003 20:01:05 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V13HAO047500; Fri, 31 Jan 2003 01:03:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V0xAf5047241; Fri, 31 Jan 2003 00:59:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 00:59:10 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V0x5AM047222 for ; Fri, 31 Jan 2003 00:59:05 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Models: preservation of user information Date: Fri, 31 Jan 2003 11:59:13 +1100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C8C3.F86742D0" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Models: preservation of user information Thread-Index: AcLIwYOAl0zUjdN7SbuhK6ckzzyxlgAAaAwg From: "Ramsay, Ron" To: "Christopher Oliva" , Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C8C3.F86742D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, the application may wish that case be preserved but, for the = directory, the issue is that case is not important for those attributes = - and the matching rule bears that out. The matching rule isn't only = used for retrieving attributes, it is also used when adding and = modifying values. The matching rule is tied up with what it means to be = a distinct, recognisable value. In any event, you should realise that = you cannot add in a 'MUST' after the event. -----Original Message----- From: Christopher Oliva [mailto:Chris.Oliva@entrust.com] Sent: Friday, 31 January 2003 11:41 To: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org Subject: RE: Models: preservation of user information It means it's not important for matching values. When I retrieve values = from the directory, I expect to get the same values I entered since I am = not asking the directory to evaluate an equality assertion. Although = upper and lower case may be equivalent, the meaning is not always the = same to applications or users. =20 Many standard attributes are already defined with caseIgnoreMatch and = can't be changed to caseExactMatch without breaking existing clients = that expect to search using the caseIgnoreMatch matching rule. =20 Chris. -----Original Message----- From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] Sent: Thursday, January 30, 2003 6:19 PM To: Christopher Oliva; ietf-ldapbis@OpenLDAP.org Subject: RE: Models: preservation of user information You should store the information in an attribute whose matching rule is = caseExactMatch. The meaning of using caseIgnoreMatch is that case is not = important. -----Original Message----- From: Christopher Oliva [mailto:Chris.Oliva@entrust.com] Sent: Friday, 31 January 2003 06:30 To: ietf-ldapbis@OpenLDAP.org Subject: Models: preservation of user information Section 6.1 includes this paragraph:=20 Where such requirements have not be explicitly stated, servers SHOULD=20 preserve the value of user information but MAY return the value in a=20 different form. And where a server is unable (or unwilling) to=20 preserve the value of user information, the server SHALL ensure that=20 an equivalent value (per Section 2.3) is returned.=20 This would allow the server to return values that are not identical to = the original values added by an application. Partly because sometimes, = equality rules only determine equivalency instead of exact equality. I think this could lead to problems. For instance, name information for = attributes with a caseIgnoreMatch equality matching rule might be = returned in the wrong case which would actually be a loss of information = for the application. I would prefer mandating servers to return the exact value that was = originally added (when there are no explicit constraints in the schema = definition for that item). Essentially this would be changing the above = paragraph to: Where such requirements have not been explicitly stated, servers MUST=20 preserve the value of user information (return the same values that=20 were originally added).=20 Chris.=20 ------_=_NextPart_001_01C2C8C3.F86742D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Models: preservation of user information
Yes,=20 the application may wish that case be preserved but, for the directory, = the=20 issue is that case is not important for those attributes - and the = matching rule=20 bears that out. The matching rule isn't only used for retrieving = attributes, it=20 is also used when adding and modifying values. The matching rule is tied = up with=20 what it means to be a distinct, recognisable value. In any event, you = should=20 realise that you cannot add in a 'MUST' after the = event.
-----Original Message-----
From: Christopher Oliva=20 [mailto:Chris.Oliva@entrust.com]
Sent: Friday, 31 January = 2003=20 11:41
To: Ramsay, Ron; = ietf-ldapbis@OpenLDAP.org
Subject:=20 RE: Models: preservation of user information

It means it's not important for matching=20 values. When I retrieve = values from=20 the directory, I expect to get the same values I entered since I am = not asking=20 the directory to evaluate an equality assertion. Although upper and lower case may be = equivalent, the=20 meaning is not always the same to applications or=20 users.
 
Many=20 standard attributes are already defined with caseIgnoreMatch and can't = be=20 changed to caseExactMatch without breaking existing clients that = expect to=20 search using the caseIgnoreMatch matching rule.
 
Chris.
-----Original Message-----
From: Ramsay, Ron=20 [mailto:Ron.Ramsay@ca.com]
Sent: Thursday, January 30, = 2003 6:19=20 PM
To: Christopher Oliva;=20 ietf-ldapbis@OpenLDAP.org
Subject: RE: Models: = preservation of=20 user information

You should store the information in an attribute whose = matching rule=20 is caseExactMatch. The meaning of using caseIgnoreMatch is that case = is not=20 important.
-----Original Message-----
From: Christopher = Oliva=20 [mailto:Chris.Oliva@entrust.com]
Sent: Friday, 31 = January 2003=20 06:30
To: ietf-ldapbis@OpenLDAP.org
Subject: = Models:=20 preservation of user information


Section 6.1 includes this paragraph:

  Where such requirements have not be = explicitly=20 stated, servers SHOULD
  preserve = the value=20 of user information but MAY return the value in a
  different form.  And where a server is unable = (or=20 unwilling) to
  preserve the value = of user=20 information, the server SHALL ensure that
 =20 an equivalent value (per Section 2.3) is returned.

This would allow the server to return values = that are not=20 identical to the original values added by an application. Partly = because=20 sometimes, equality rules only determine equivalency instead of = exact=20 equality.

I think this could lead to problems. For = instance, name=20 information for attributes with a caseIgnoreMatch equality = matching rule=20 might be returned in the wrong case which would actually be a loss = of=20 information for the application.

I would prefer mandating servers to return the = exact value=20 that was originally added (when there are no explicit constraints = in the=20 schema definition for that item). Essentially this would be = changing the=20 above paragraph to:

  Where such requirements have not been = explicitly=20 stated, servers MUST
  preserve the = value of=20 user information (return the same values that
  were originally added).

Chris.=20

------_=_NextPart_001_01C2C8C3.F86742D0-- From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 23:31:42 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18424 for ; Thu, 30 Jan 2003 23:31:42 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V4XNAO022557; Fri, 31 Jan 2003 04:33:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V4OAMR017528; Fri, 31 Jan 2003 04:24:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 04:24:10 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h0V4O4AM017300 for ; Fri, 31 Jan 2003 04:24:06 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 15766 invoked from network); 31 Jan 2003 04:22:55 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 31 Jan 2003 04:22:55 -0000 Reply-To: From: "Steven Legg" To: "'Christopher Oliva'" , Subject: RE: Models: preservation of user information Date: Fri, 31 Jan 2003 15:22:12 +1100 Message-ID: <003b01c2c8e0$54b32010$a518200a@osmium.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, Christopher Oliva wrote: > Section 6.1 includes this paragraph: > > Where such requirements have not be explicitly stated, servers SHOULD > preserve the value of user information but MAY return the value in a > different form. And where a server is unable (or unwilling) to > preserve the value of user information, the server SHALL ensure that > an equivalent value (per Section 2.3) is returned. > > This would allow the server to return values that are not identical to > the original values added by an application. Partly because sometimes, > equality rules only determine equivalency instead of exact equality. > > I think this could lead to problems. For instance, name information for > attributes with a caseIgnoreMatch equality matching rule might be returned > in the wrong case which would actually be a loss of information for the > application. > > I would prefer mandating servers to return the exact value that was > originally added (when there are no explicit constraints in the schema > definition for that item). Essentially this would be changing the above > paragraph to: > > Where such requirements have not been explicitly stated, servers MUST > preserve the value of user information (return the same values that > were originally added). LDAP + X.500 servers cannot, in general, preserve the exact octet encoding of attribute values presented in the LDAP-specific encoding. This is because attribute values have to be re-encoded in BER for transfer between directory servers. In theory, they aren't supposed to rely on preserving the exact BER encoding of an attribute value either, but in practice they have to. The strongest requirement that can be placed on X.500 directory servers is that they preserve the abstract value (in the ASN.1 sense) of an attribute value, regardless of the encoding in which it was originally presented. I consider it desirable for directory servers to always preserve the abstract value, though X.500 provides no guidance on this issue. That fact that matching rules other than the equality matching rule for an attribute can be applied to the attribute's values through an extensible match is indicative of an expectation that attribute values should be distinguishable at a deeper level than just equivalence according to the attribute's equality matching rule. ASN.1 abstract value equivalence is as deep as I'm able to go. In ASN.1, two values of a string syntax that differ only in letter case are regarded as different values. Likewise for two string values that have different amounts of leading, trailing or separating white space. Thus I consider it prudent for directory servers to preserve the exact letter case and amount of white space in values of string syntaxes, regardless of the equality matching rule for the attribute. However, I can't point to a paragraph of any directory standard that requires this. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 23:40:40 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18613 for ; Thu, 30 Jan 2003 23:40:39 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V4hCAO025578; Fri, 31 Jan 2003 04:43:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V4XI8V022508; Fri, 31 Jan 2003 04:33:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 04:33:18 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h0V4XDAM022441 for ; Fri, 31 Jan 2003 04:33:14 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 17062 invoked from network); 31 Jan 2003 04:32:04 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 31 Jan 2003 04:32:04 -0000 Reply-To: From: "Steven Legg" To: "'Jim Sermersheim'" , Subject: RE: Models: Matching Rule Uses Date: Fri, 31 Jan 2003 15:31:22 +1100 Message-ID: <003c01c2c8e1$9c5ef1e0$a518200a@osmium.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > Why not? No reason why not. X.500 doesn't restrict what matching rules can be used in an extensible match. Directory administrators may be able to, depending on how one interprets the matchingRuleUse attribute. Regards, Steven > I may have an attribute who's syntax is caseExactMatch. I may > want to search for values of that attribute using an extensible match > filter where the rule is caseIgnoreMatch. > > Jim > > >>> "Ramsay, Ron" 1/30/03 4:30:59 PM >>> > caseIgnoreMatch is not an *extensible* matching rule. > > -----Original Message----- > From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] > Sent: Friday, 31 January 2003 09:34 > To: ietf-ldapbis@OpenLDAP.org > Subject: Models: Matching Rule Uses > > > [Models] says: > > > 4.1.4. Matching Rule Uses > > > > A matching rule use lists the attributes which are suitable for use > > with an extensible matching rule > > Please add something like "(in addition to those uses expressed in > AttributeType descriptions)". > > BTW, how do Matching Rule Uses relate to the statements in [Syntaxes] > about which matching rules can be used with which syntaxes? > For example, [Syntaxes] 5.2.6 says: > > > The caseIgnoreMatch rule compares an assertion value of the > Directory > > String syntax to an attribute value of a syntax (e.g. the > Directory > > String, Printable String, Country String or Telephone Number > syntax) > > whose corresponding ASN.1 type is DirectoryString or one of its > > alternative string types, e.g. PrintableString. > > -- > Hallvard > > > From owner-ietf-ldapbis@OpenLDAP.org Thu Jan 30 23:50:40 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18863 for ; Thu, 30 Jan 2003 23:50:40 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V4rDAO030446; Fri, 31 Jan 2003 04:53:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V4k3Jp027739; Fri, 31 Jan 2003 04:46:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 04:46:03 +0000 Received: from ausyms50.ca.com ([155.35.248.106]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V4jxAM027340 for ; Fri, 31 Jan 2003 04:45:59 GMT (envelope-from Ron.Ramsay@ca.com) content-class: urn:content-classes:message Subject: RE: Models: preservation of user information Date: Fri, 31 Jan 2003 15:45:50 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Models: preservation of user information Thread-Index: AcLI4f8n2yv3etCoRoay1p+N14llSgAATCIA From: "Ramsay, Ron" To: , "Christopher Oliva" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h0V4k0AM027676 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Surely no server which supports both LDAPv2 and LDAPv3 can come close to this?? The ASN.1 form you are talking about would presumably be the UTF-8 variant of directoryString which would have to be invented from the original LDAPv2 T.61? Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Friday, 31 January 2003 15:22 To: 'Christopher Oliva'; ietf-ldapbis@OpenLDAP.org Subject: RE: Models: preservation of user information Chris, Christopher Oliva wrote: > Section 6.1 includes this paragraph: > > Where such requirements have not be explicitly stated, servers SHOULD > preserve the value of user information but MAY return the value in a > different form. And where a server is unable (or unwilling) to > preserve the value of user information, the server SHALL ensure that > an equivalent value (per Section 2.3) is returned. > > This would allow the server to return values that are not identical to > the original values added by an application. Partly because sometimes, > equality rules only determine equivalency instead of exact equality. > > I think this could lead to problems. For instance, name information for > attributes with a caseIgnoreMatch equality matching rule might be returned > in the wrong case which would actually be a loss of information for the > application. > > I would prefer mandating servers to return the exact value that was > originally added (when there are no explicit constraints in the schema > definition for that item). Essentially this would be changing the above > paragraph to: > > Where such requirements have not been explicitly stated, servers MUST > preserve the value of user information (return the same values that > were originally added). LDAP + X.500 servers cannot, in general, preserve the exact octet encoding of attribute values presented in the LDAP-specific encoding. This is because attribute values have to be re-encoded in BER for transfer between directory servers. In theory, they aren't supposed to rely on preserving the exact BER encoding of an attribute value either, but in practice they have to. The strongest requirement that can be placed on X.500 directory servers is that they preserve the abstract value (in the ASN.1 sense) of an attribute value, regardless of the encoding in which it was originally presented. I consider it desirable for directory servers to always preserve the abstract value, though X.500 provides no guidance on this issue. That fact that matching rules other than the equality matching rule for an attribute can be applied to the attribute's values through an extensible match is indicative of an expectation that attribute values should be distinguishable at a deeper level than just equivalence according to the attribute's equality matching rule. ASN.1 abstract value equivalence is as deep as I'm able to go. In ASN.1, two values of a string syntax that differ only in letter case are regarded as different values. Likewise for two string values that have different amounts of leading, trailing or separating white space. Thus I consider it prudent for directory servers to preserve the exact letter case and amount of white space in values of string syntaxes, regardless of the equality matching rule for the attribute. However, I can't point to a paragraph of any directory standard that requires this. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 00:41:33 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19737 for ; Fri, 31 Jan 2003 00:41:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0V5hGAO045666; Fri, 31 Jan 2003 05:43:22 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0V5ccR8045493; Fri, 31 Jan 2003 05:38:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 05:38:38 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h0V5cWAM045477 for ; Fri, 31 Jan 2003 05:38:33 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 26545 invoked from network); 31 Jan 2003 05:37:22 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 31 Jan 2003 05:37:22 -0000 Reply-To: From: "Steven Legg" To: "'Ramsay, Ron'" , Subject: RE: Models: preservation of user information Date: Fri, 31 Jan 2003 16:36:40 +1100 Message-ID: <003d01c2c8ea$bba59a50$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003E_01C2C946.EF161250" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-MS-TNEF-Correlator: 00000000959925F7459DD311B46500E02915D5DBC4A84400 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C2C946.EF161250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ron, Ramsay, Ron wrote: > Surely no server which supports both LDAPv2 and LDAPv3 can > come close to this?? The ASN.1 form you are talking about > would presumably be the UTF-8 variant of directoryString > which would have to be invented from the original LDAPv2 T.61? Huh? If a value of an attribute with the Directory String syntax is presented to our server in LDAPv2 as T.61 then we preserve it in the teletexString alternative of the DirectoryString{} ASN.1 type. It gets transferred to other DSAs in this same encoding. If a value of an attribute with the Directory String syntax is presented to our server in LDAPv3 then we have to choose an alternative of the DirectoryString CHOICE, but having chosen, the value always gets transferred to other DSAs as that alternative and encoding. Thus we are preserving the abstract value in both cases as far as ASN.1 is concerned. When a DirectoryString{} value is encoded for an LDAP result we transliterate as required and the LDAP user sees exactly the octets they put in. Regards. Steven > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Friday, 31 January 2003 15:22 > To: 'Christopher Oliva'; ietf-ldapbis@OpenLDAP.org > Subject: RE: Models: preservation of user information > > > > Chris, > > Christopher Oliva wrote: > > Section 6.1 includes this paragraph: > > > > Where such requirements have not be explicitly stated, > servers SHOULD > > preserve the value of user information but MAY return the > value in a > > different form. And where a server is unable (or unwilling) to > > preserve the value of user information, the server SHALL > ensure that > > an equivalent value (per Section 2.3) is returned. > > > > This would allow the server to return values that are not > identical to > > the original values added by an application. Partly because > sometimes, > > equality rules only determine equivalency instead of exact equality. > > > > I think this could lead to problems. For instance, name > information for > > attributes with a caseIgnoreMatch equality matching rule > might be returned > > in the wrong case which would actually be a loss of > information for the > > application. > > > > I would prefer mandating servers to return the exact value that was > > originally added (when there are no explicit constraints in > the schema > > definition for that item). Essentially this would be > changing the above > > paragraph to: > > > > Where such requirements have not been explicitly stated, > servers MUST > > preserve the value of user information (return the same > values that > > were originally added). > > LDAP + X.500 servers cannot, in general, preserve the exact > octet encoding > of attribute values presented in the LDAP-specific encoding. > This is because > attribute values have to be re-encoded in BER for transfer > between directory > servers. In theory, they aren't supposed to rely on > preserving the exact BER > encoding of an attribute value either, but in practice they > have to. The > strongest requirement that can be placed on X.500 directory > servers is that > they preserve the abstract value (in the ASN.1 sense) of an > attribute value, > regardless of the encoding in which it was originally > presented. I consider > it desirable for directory servers to always preserve the > abstract value, > though X.500 provides no guidance on this issue. > > That fact that matching rules other than the equality > matching rule for > an attribute can be applied to the attribute's values through > an extensible > match is indicative of an expectation that attribute values should be > distinguishable at a deeper level than just equivalence > according to the > attribute's equality matching rule. ASN.1 abstract value > equivalence is > as deep as I'm able to go. > > In ASN.1, two values of a string syntax that differ only in > letter case > are regarded as different values. Likewise for two string values that > have different amounts of leading, trailing or separating white space. > Thus I consider it prudent for directory servers to preserve the exact > letter case and amount of white space in values of string syntaxes, > regardless of the equality matching rule for the attribute. However, > I can't point to a paragraph of any directory standard that > requires this. > > Regards, > Steven > > > > ------=_NextPart_000_003E_01C2C946.EF161250 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IikFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHAQAfABAAJAAAAAUAMwEB A5AGAHgOAAAqAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAACkAAABNb2RlbHM6IHByZXNlcnZhdGlvbiBvZiB1c2VyIGluZm9y bWF0aW9uAAAAAAIBcQABAAAAFgAAAAHCyOq64P2cxB40nBHXoRIAgMhOafUAAAIBHQwBAAAAHwAA AFNNVFA6U1RFVkVOLkxFR0dAQURBQ0VMLkNPTS5BVQAACwABDgAAAABAAAYOAKDbourIwgECAQoO AQAAABgAAAAAAAAAlZkl90Wd0xG0ZQDgKRXV28KAAAADABQOAQAAAAsAHw4BAAAAAwAGEFWmX6YD AAcQSg0AAB4ACBABAAAAZQAAAFJPTixSQU1TQVksUk9OV1JPVEU6U1VSRUxZTk9TRVJWRVJXSElD SFNVUFBPUlRTQk9USExEQVBWMkFORExEQVBWM0NBTkNPTUVDTE9TRVRPVEhJUz8/VEhFQVNOMUZP Uk1ZT1UAAAAAAgEJEAEAAADDCQAAvwkAAMcUAABMWkZ1ArO9DgMACgByY3BnMTI14jIDQ3RleAVB AQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzAS LBEzCO8J97Y7GB8OMDURIgxgYwBQswsJAWQzNhZQC6djATBnCuMKgAgAbiwdNB01YWBtc2F5LAfx A6B3awNgDrA6HTQ+BgAIcGVAbHkgbm8gFBByUnYSgXdoDeBoIMB1XHBwF8EEIAbgdCGATLBEQVB2 FEAAcGQidPgzIGMDkh/FBaAHgCOQcxewFBAgdCCwIlAEAD8QPyBUaCSQQVNOCC4xIAIQcm0geV8I YCLgGCAlAAdAawuAZ1si4AbgdQVBH8V3CGBsfSMQcBggIaAAwAJgIIBiAyTxJcFVVEYtOCAOdgrA BzACMCBvZiAUZGkYIGMlEHJ5U/50BRAncSgHIVMohBPgIQD/JQIpkQuAIQACMAmAJkADYXMpswWw aWcLgAdAInZUEC42MT8d2kh1aPUlkEkq8GEqUQpBKtIDkfZhAkAFEGIn0CSQA/AiUZ0pwkQrJgYA K7RzeQIw/GF4HTQEACjTLjQlEQhh/yDGC4AidwQgMCIpsh8xJJD3NcMg8S3wdDU1A6Apwg6w/mwU IA7AK6UHQA6wBKAykF5pLXEq4TOLK6RcAAB9QSXldHlwZS4dNEm9BUBnFCAEICuwAHFmBJCPGCE2 UynBBcBEU0EEIP858zWRHsAkgQnwBaArECdwvz5WMZ8yrzO/NMUt8HMdNL81zzbdI4A4Zi1WE9Bv JNIfAHAdNDtPPF8SIEhPSfxDRR7wRAEtQidiSgFHEe8dxSnCQvQHQHce0AQgPv//QAw34SJQQ7A7 OkqVIwFBt/0loXUEIDixJuI45SdiKcL9AaBzUIErUELlN0EiMh009yOgFBBSA2YKwTfhJfQ1kd8F oEHABJEJgFRwVzhyQtD/PH89gULzNTdBsy5iBbEDkb0igiAo8ksAOKJQg2xEYJ8EkEOwSlEEIBgg cXUrIf8jECLyKcEdNF3DVLASgRQQ/weRDsBWkSBxLuMrUFBDJcA9IIBwJ9ELgD5VHTVlZ+0LEXM+ VSugZS4hHdogEK8fth2RPlVmyC1ook8vNr5NB5AewFAwaKMftkYDYb46NFFlwiJwZNAngFsAwNsD ECUQOlZgZcIuOoBrsFhAYWQA0CBgLiRhLnhhdV0fty4xawBqwGmrbTAe4TMmMEoAcHUKwAsggAHQ MCOAMTU6MgsOUB/FVGxAICdDaNMFEFZgb3BAUk9fACpgTCc7LfAUIGYtKLBhpHBiBABATz4wbiKC zi4FsD1QH8diaitBawCUUkVrAE0EcWxzawD/OOVLUR8hKuFhcwuAJlJ2k/9mbmZucYMdxXmNcdof TW5i+ytQdrI2WTJBwApAAQBSMv81kgrAacBQkHHwfPh9CIEA/1pBJvEhoCFxX8UHgAIwBCD/LVMg oAVAKZEOwAtQDeBEYPcgcVZgX1FkHvAftiDUBkH9TTBVIoCAejjnTyh2/x8h0U2iTUFZXgF0CHA6 BPsftlbXYYB6KxABIIFRKrH/JlJUcBDAIwEhQIFSQtA21t0EIHUvcAJgJJAoBbGOsO0D8GxfACdw KSUBhg+HHx93Lh7wKcIg1YWgQUxM/yPXCfAhoCbyUmGAegORX9J3QvGMokL0KD4wlAF9tTL8LjOP 8DWRibRaAX/vcRH/QSIohAdAF7AH4JN5JRGJtf9C81I2JvGDAh+2bwAuMQ3gvy+BkBou650lbSBd EmIggN9DgiHAg6F2k1RwUArAYlL/KZAjoGFxhJgkcUtgB4F6d9+U4V/gB0BEYCCAciigB5HvAiAg cQEASxFtC4BBkZa2/mMggAuAbGFtICrSYhOlt8uZj31xSSUybmtBBAWg3yiiOoCosSURKOBvjuEe sP1UcEYFsahiAHBZwB7wL3D/JIGeZ4iJJlF9CEO3VMFEYrNC0FgCSWcgoBggTUOw/yFxpcd3wRPQ J2KmUiPXp1D8Z2iDI5kGfQg59R9RTiL/WBEsi1aRpeEpZELQJMGmkf8q8K6/r8RgiLCDolmqD6sS /yiHUNGzYSMAS1E0ooU1nIj/KcKpFEL0UlNP4EZ1fWIvJvsgcaGEKI2ROgONwp3zg2f/WYJWYguA IgE3QR+2k3MT0P+CQIt5AQELgERgushScV8R9G0pVHBFBBCfArijQRO/KIQpkSPnE+AncFXIb1M2 /31if0clAX/fgO+B/4MEOIHHg3+EjwXQVVNUkD+RT/2ILyiJuUFjimtSNM9KOLAfJvHC3snQZm5d wysgWPwuNXAghRcjoYMBHvA3QfdQMFnwUJBsHvDVm6kUH7b/YtNBp+E3QrFDx50lRug59bkigi1z PjDSsMhwY1Pp/3C3QSI1kaOFH7bjTy1ZGCDGLVzWN0FCRVK69FCV+yPXKZB0OLA4gSsXhK1UcL5J OgMrcZNTofGMkScFQP8hoxQQR2MgUx8hH7ZVXakU3+txlIhB1ENPQvRlRGEEkP9NhDdBKOBWkQ3g KaMggB+2/y1VVHK7Z1ZhtxEHkAVA0Ln/UkQjoimRC1FZwKjBA6Dd5H8rF9OPNZGVemNE1apWTSj/ OfUl9EcRFBCP8ENU6F9C5P96dxggZOKmcblzwLP0ZjdB/yFExXHCAdtK8dsuQu8BxZP/nuGwF8Vx frFE8I7TXVL8+P+/mU/F1ZsDR1ZbenciUCfAv7Tw3dWs4U4AfrIgoWdf8P9tMFmx8ZJBE3uwIaA+ RmbI/yWwUnFYkPNxUlOze6aRQEP/UlHAlaXWtFezi6/5Q4v7he+iQ0dUAGP1ViehYJ0ntwD/ELIZ eTqwqJAKEY7hF+tZUv8vYCsQopJLhB5T5cHTIXay+1JU415zEJHLQ2gmKxBWYL8nYV/wI2CO01Jy pvFll8LvOoDUQJ9hFtJqVLCpU6fV/Q55Y6wABYBVwxvDA08csf+y76ZDVHBZBFZN89cnSUZmj7Ch oWAlwjfSSSdtzOH7jvHqMWf48GZu7yFZA5NR/74gnRZDUvnCRblSU4xEpqT/xmk6gUsRsdMpd5VB BURgIg8vcYxXnSRUcExpa2X/sXCj0bsDMrEzpdmf+HWMSP9BcBCggnKo4axiThGTUcXx/4+yoHHU Ac3iv0O3oUQh5bD//BG8x1STCdgHcqzgfqGMtP8L/7/z4A+VpzZJYEM9NKjS/z/pNYIy6DOrpPkF TyqvGNj7G9xUcEiboGXB9pAxhxqy//Bh8MDGEQ0Tzdkg46bhQyj/rfFtMAWAnYRKOF/jftQw/19k xXp3Zap5D1ftfVlgAAMAEBAAAAAAAwAREAQAAAAeAEIQAQAAADsAAAA8QTdFM0E0QjUxNjE1RDUx MUJDQjYwMDkwMjdEMEQxOEMwN0JDRDNENEBhc3BhbXMwMS5jYS5jb20+AAALAACACCAGAAAAAADA AAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAIgAgg BgAAAAAAwAAAAAAAAEYAAAAAUoUAADwYAAAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAA AAQAAAA4LjUACwAKgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAuACCAGAAAAAADAAAAA AAAARgAAAAABhQAAAAAAAAsAFIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAVgAggBgAA AAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADABeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4A JoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeACeACCAGAAAAAADAAAAAAAAA RgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAogAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAA AAAAAAsAM4ALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA1gAsgBgAAAAAAwAAAAAAAAEYA AAAABYgAAAAAAAACAfgPAQAAABAAAACVmSX3RZ3TEbRlAOApFdXbAgH6DwEAAAAQAAAAlZkl90Wd 0xG0ZQDgKRXV2wIB+w8BAAAASQAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAA AE5JVEH5v7gBAKoAN9luAAAASTpcbWFpbFxtYWlsYm94LnBzdAAAAAADAP4PBQAAAAMADTT9NwAA AgF/AAEAAAAxAAAAMDAwMDAwMDA5NTk5MjVGNzQ1OUREMzExQjQ2NTAwRTAyOTE1RDVEQkM0QTg0 NDAwAAAAAEyv ------=_NextPart_000_003E_01C2C946.EF161250-- From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 12:58:20 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13805 for ; Fri, 31 Jan 2003 12:58:20 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHhGKG030861; Fri, 31 Jan 2003 18:01:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VHccW2019052; Fri, 31 Jan 2003 17:38:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 17:38:38 +0000 Received: from cantor.openldap.org (root@cantor.openldap.org [IPv6:2001:4f8:3:ba:206:29ff:fe1f:3f3e]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHVmTc065865; Fri, 31 Jan 2003 17:38:30 GMT (envelope-from hbf@bombur.uio.no) Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by cantor.openldap.org (8.12.6/8.12.6) with ESMTP id h0VBK77c020048; Fri, 31 Jan 2003 11:20:08 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18eZD8-0002Cb-00; Fri, 31 Jan 2003 12:19:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eZD8-0002j2-00; Fri, 31 Jan 2003 12:19:54 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: aliases In-Reply-To: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> References: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 31 Jan 2003 12:19:54 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: > You need to add extensibleObject, an objectClass > which SUPs alias and allows o, or adjust your DIT > content rules to allow o in alias entries. Could you please add that as a note to [Models] 2.6 (Alias Entries)? BTW, unless someone answered that to my other mail: Why not another auxiliary class than extensibleObject? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 12:58:26 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13842 for ; Fri, 31 Jan 2003 12:58:25 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHhGKI030861; Fri, 31 Jan 2003 18:01:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VHccrG019072; Fri, 31 Jan 2003 17:38:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 17:38:38 +0000 Received: from cantor.openldap.org (root@cantor.openldap.org [IPv6:2001:4f8:3:ba:206:29ff:fe1f:3f3e]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHVmTe065865; Fri, 31 Jan 2003 17:38:30 GMT (envelope-from hbf@bombur.uio.no) Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by cantor.openldap.org (8.12.6/8.12.6) with ESMTP id h0VBFH7c019732; Fri, 31 Jan 2003 11:15:19 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18eZ8Y-0000qp-00; Fri, 31 Jan 2003 12:15:10 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eZ8X-0002ii-00; Fri, 31 Jan 2003 12:15:09 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: aliases In-Reply-To: <5.2.0.9.0.20030130141306.019f77e8@127.0.0.1> References: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> <5.2.0.9.0.20030130141306.019f77e8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 31 Jan 2003 12:15:09 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >> It seems rather heavy to force people to get their >> own OID and make new object classes just in order >> to use aliases, if extensibleObject is not supported >> on their server. > > Some could publish a "Common subclasses of 'alias'" > technical specification.... Good idea. Though it seems enough with one subclass 'namedAlias' with several MAY attributes. I suggest: - the attributes in the table in [DN] 2.3: cn, l, st, o, ou, c, street, dc, uid, - the other 'SUP name' attributes in [Schema]: generationQualifier, givenName, initials, sn, title. (If the registry approach is used in [DN], any additional attributes from the registry should be added if there are not too many yet.) ...or a 'namedObject' auxiliary class with those MAY attributes. What's the advantage of a subclass over an auxiliary class? Everyone says subclass, but I like auxiliary classes - they are reusable. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 12:58:28 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13890 for ; Fri, 31 Jan 2003 12:58:28 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHhGKC030861; Fri, 31 Jan 2003 18:01:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VHQfwR097810; Fri, 31 Jan 2003 17:26:41 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 17:26:41 +0000 Received: from cantor.openldap.org (root@cantor.openldap.org [IPv6:2001:4f8:3:ba:206:29ff:fe1f:3f3e]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHEBmC065865 for ; Fri, 31 Jan 2003 17:26:37 GMT (envelope-from hbf@bombur.uio.no) Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by cantor.openldap.org (8.12.6/8.12.6) with ESMTP id h0VD467c024513 for ; Fri, 31 Jan 2003 13:04:07 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18eapm-0006AP-00; Fri, 31 Jan 2003 14:03:54 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eapm-0002yu-00; Fri, 31 Jan 2003 14:03:54 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: ORDERING rules vs. lessOrEqual filters Date: Fri, 31 Jan 2003 14:03:54 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Syntaxes] 5.2.7 and 5.2.11 say the -OrderingMatch matching rules evaluate to TRUE if and only if the attribute value is "less than" the assertion value. [Protocol] 4.5.1 says The matching rule and assertion syntax for greaterOrEqual and lessOrEqual filter items is defined by the ORDERING matching rule for the attribute type. How? OK, a greaterOrEqual filter returns (not (result of the ORDERING matching rule)). But how is a lessOrEqual filter evaluated? Does it swap the assertion value and the attribute value, or must ORDERING matching rules be implemented internally to return three values (less, equal, greater) in addition to Undefined? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 13:20:40 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14538 for ; Fri, 31 Jan 2003 13:20:40 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VINNAO046588; Fri, 31 Jan 2003 18:23:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VIIPr4046374; Fri, 31 Jan 2003 18:18:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 18:18:25 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIILAM046365 for ; Fri, 31 Jan 2003 18:18:21 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18efk2-0006t4-00; Fri, 31 Jan 2003 19:18:18 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18efk1-0003o9-00; Fri, 31 Jan 2003 19:18:17 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Models: DIT Content Rules and AUX object classes Date: Fri, 31 Jan 2003 19:18:17 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Models] 4.1.6 (DIT Content Rules) says: An entry may only belong to auxiliary object classes listed in the governing content rule. Even if the content rule has no AUX part? If so, is it possible to specify that all auxiliary object classes are allowed? Or does no AUX mean that all auxiliary object classes are allowed? If so, I suggest it is added that e.g. "AUX 1.1" can be used to say 'no auxiliary objectclasses are allowed'. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 13:38:32 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15033 for ; Fri, 31 Jan 2003 13:38:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIXHAi047237; Fri, 31 Jan 2003 18:41:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VIRhoh046903; Fri, 31 Jan 2003 18:27:43 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 18:27:43 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIRdAM046894 for ; Fri, 31 Jan 2003 18:27:39 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0VIRU8O063183; Fri, 31 Jan 2003 18:27:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030131102420.01a0e050@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Jan 2003 10:26:05 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: DIT Content Rules and AUX object classes Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:18 AM 1/31/2003, Hallvard B Furuseth wrote: >[Models] 4.1.6 (DIT Content Rules) says: > > An entry may only belong to auxiliary object classes listed in the > governing content rule. > >Even if the content rule has no AUX part? If so, is it possible to >specify that all auxiliary object classes are allowed? For servers which behave in accordance with X.500, no. >Or does no AUX mean that all auxiliary object classes are allowed? No. >If so, I suggest it is added that e.g. "AUX 1.1" can be used to say >'no auxiliary objectclasses are allowed'. That would be an extension to the existing schema model and hence beyond scope of this document. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 13:39:10 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15074 for ; Fri, 31 Jan 2003 13:39:10 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIXHAk047237; Fri, 31 Jan 2003 18:41:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VIVrZJ047099; Fri, 31 Jan 2003 18:31:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 18:31:53 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIVnAM047088 for ; Fri, 31 Jan 2003 18:31:49 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0VIVe8O063207; Fri, 31 Jan 2003 18:31:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030131102647.023e8958@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Jan 2003 10:30:14 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: aliases Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 03:19 AM 1/31/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> You need to add extensibleObject, an objectClass >> which SUPs alias and allows o, or adjust your DIT >> content rules to allow o in alias entries. > >Could you please add that as a note to [Models] 2.6 >(Alias Entries)? Yes. >BTW, unless someone answered that to my other mail: >Why not another auxiliary class than extensibleObject? Another auxiliary class could be used. For example, dcObject could be used to allow "dc=foo" as a naming attribute. The reason why structural subclasses of alias are more commonly used is that structural rules can be associated with them. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 13:41:14 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15137 for ; Fri, 31 Jan 2003 13:41:13 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIhGAO047840; Fri, 31 Jan 2003 18:43:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VIYvKJ047402; Fri, 31 Jan 2003 18:34:57 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 18:34:57 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIYrAM047391 for ; Fri, 31 Jan 2003 18:34:53 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0VIYi8O063244; Fri, 31 Jan 2003 18:34:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030131103040.01a25b98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Jan 2003 10:33:19 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: aliases Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030130141306.019f77e8@127.0.0.1> <5.2.0.9.0.20030129105920.019fc638@127.0.0.1> <5.2.0.9.0.20030130141306.019f77e8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 03:15 AM 1/31/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> It seems rather heavy to force people to get their >>> own OID and make new object classes just in order >>> to use aliases, if extensibleObject is not supported >>> on their server. >> >> Some could publish a "Common subclasses of 'alias'" >> technical specification.... > >Good idea. Though it seems enough with one subclass 'namedAlias' >with several MAY attributes. Actually, I think one would one to create one subclass of alias for each class used in aliased object. That is, personAlias, inetOrgPersonAlias, ... not cnAlias so that one can better place structure rules/name forms. >...or a 'namedObject' auxiliary class with those MAY attributes. >What's the advantage of a subclass over an auxiliary class? structure rules/name forms. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 13:43:30 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13806 for ; Fri, 31 Jan 2003 12:58:20 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHhGKE030861; Fri, 31 Jan 2003 18:01:02 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VHT5BF004888; Fri, 31 Jan 2003 17:29:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 17:29:05 +0000 Received: from cantor.openldap.org (root@cantor.openldap.org [IPv6:2001:4f8:3:ba:206:29ff:fe1f:3f3e]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHEBuu065865 for ; Fri, 31 Jan 2003 17:29:00 GMT (envelope-from hbf@bombur.uio.no) Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by cantor.openldap.org (8.12.6/8.12.6) with ESMTP id h0VCdK7c023320 for ; Fri, 31 Jan 2003 12:39:21 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18eaRq-00020d-00; Fri, 31 Jan 2003 13:39:10 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eaRq-0002vi-00; Fri, 31 Jan 2003 13:39:10 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: How are approxMatch matching rules declared? Date: Fri, 31 Jan 2003 13:39:10 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Models] 4.1.2 (Attribute Types) has no ["APPROX" SP oid] part which can be used to declare the matching rule which approxMatch filters on the attribute should use. Should that be fixed? Or must an implementation which wants to use implement approxMatch define a syntax like ["X-APPROX" SP oid] ; approxMatch matching rule or do something like defining an implicit approx matching rule for each syntax which supports approxMatch filters? Should [Models] say something about this? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 13:43:31 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13843 for ; Fri, 31 Jan 2003 12:58:25 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHhGKK030861; Fri, 31 Jan 2003 18:01:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VHT2i6004742; Fri, 31 Jan 2003 17:29:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 17:29:02 +0000 Received: from cantor.openldap.org (root@cantor.openldap.org [IPv6:2001:4f8:3:ba:206:29ff:fe1f:3f3e]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VHEBum065865 for ; Fri, 31 Jan 2003 17:28:56 GMT (envelope-from hbf@bombur.uio.no) Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by cantor.openldap.org (8.12.6/8.12.6) with ESMTP id h0VCmp7c023872 for ; Fri, 31 Jan 2003 12:48:51 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18eaaw-00035S-00; Fri, 31 Jan 2003 13:48:34 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18eaao-0002xB-00; Fri, 31 Jan 2003 13:48:26 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Ramsay, Ron" Cc: Jim Sermersheim , ietf-ldapbis@OpenLDAP.org Subject: RE: Models: Matching Rule Uses In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 31 Jan 2003 13:48:26 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ramsay, Ron writes: > From: "Ramsay, Ron" > To: "Jim Sermersheim" , > Subject: RE: Models: Matching Rule Uses > Date: Fri, 31 Jan 2003 11:52:37 +1100 > > I should think the normal use of a matching rule is in the > 'equalityMatch' choice of the filter. Also substrings, greaterOrEqual and lessOrEqual. > I also think 'extensibleMatch' is an attempt to create a new semantic > and that the paragraphs below provide the means to scope this new > meaning. The use of the matching rule in an attribute definition is > automatically scoped. Yup. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 14:00:48 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15588 for ; Fri, 31 Jan 2003 14:00:47 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VJ3NAO048858; Fri, 31 Jan 2003 19:03:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VItR8H048636; Fri, 31 Jan 2003 18:55:27 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 18:55:27 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VItNAM048625 for ; Fri, 31 Jan 2003 18:55:23 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h0VItE8O063446; Fri, 31 Jan 2003 18:55:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030131104954.01a044a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Jan 2003 10:53:49 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: preservation of user information Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:26 AM 1/31/2003, Hallvard B Furuseth wrote: >Christopher Oliva writes: >> I would prefer mandating servers to return the exact value that was >> originally added (when there are no explicit constraints in the schema >> definition for that item). > >Well, that has been shot down, but maybe this sentence in [Models] 6.1: > > Where such requirements have not be explicitly stated, servers SHOULD > preserve the value of user information but MAY return the value in a > different form. > >can be strengthened a little: Append > > ..."provided that the implementation documents possible divergences." Interoperability should not depend on the availability of documentation of implementations. From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 14:28:31 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15032 for ; Fri, 31 Jan 2003 13:38:32 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIXHAg047237; Fri, 31 Jan 2003 18:41:13 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VIQQnI046814; Fri, 31 Jan 2003 18:26:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 18:26:26 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VIQMAM046802 for ; Fri, 31 Jan 2003 18:26:22 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18efrm-0007JN-00; Fri, 31 Jan 2003 19:26:18 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18efrm-0003pd-00; Fri, 31 Jan 2003 19:26:18 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: preservation of user information Date: Fri, 31 Jan 2003 19:26:18 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Christopher Oliva writes: > I would prefer mandating servers to return the exact value that was > originally added (when there are no explicit constraints in the schema > definition for that item). Well, that has been shot down, but maybe this sentence in [Models] 6.1: Where such requirements have not be explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. can be strengthened a little: Append ..."provided that the implementation documents possible divergences." -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 15:04:40 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17315 for ; Fri, 31 Jan 2003 15:04:39 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VK3RAS051551; Fri, 31 Jan 2003 20:07:17 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VJvXmb050896; Fri, 31 Jan 2003 19:57:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 19:57:33 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VJvSAM050881 for ; Fri, 31 Jan 2003 19:57:29 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18ehHx-0004A5-00; Fri, 31 Jan 2003 20:57:25 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ehHx-00042t-00; Fri, 31 Jan 2003 20:57:25 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Models: Change of structural object class Date: Fri, 31 Jan 2003 20:57:25 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: [Models] 3.3 (The 'objectClass' attribute) says: Servers which follow X.500(93) models SHALL restrict modifications of this attribute to prevent the basic structural class of the entry from being changed. That is, one cannot change a 'person' into a 'country'. This statement is redundant, because 2.4.2 (Structural Object Classes) says: The structural object class of an entry shall not be changed. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 15:04:46 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17346 for ; Fri, 31 Jan 2003 15:04:46 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VK3RAW051551; Fri, 31 Jan 2003 20:07:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VJvoeF050931; Fri, 31 Jan 2003 19:57:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 19:57:50 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VJvjAM050917 for ; Fri, 31 Jan 2003 19:57:46 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18ehID-0002lj-00; Fri, 31 Jan 2003 20:57:41 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ehID-00042v-00; Fri, 31 Jan 2003 20:57:41 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Models: structural subclass of auxiliary object class Date: Fri, 31 Jan 2003 20:57:41 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I've just realized that there is one time it might make sense for an auxiliary object class to subclass a structural class, which [Models] 2.4.3 disallows: With multiple inheritance ([Models] 2.4), one might want a structural object class which inherits from one structural class and one or more auxiliary classes. I suppose there is some risk that we'll meet an X.500 installation which does that and thus cannot gateway to LDAP. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 15:20:39 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17715 for ; Fri, 31 Jan 2003 15:20:38 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VKNNAO052824; Fri, 31 Jan 2003 20:23:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VKLSAQ052780; Fri, 31 Jan 2003 20:21:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 20:21:28 +0000 Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VKLJAM052755; Fri, 31 Jan 2003 20:21:20 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18ehf2-00060l-00; Fri, 31 Jan 2003 21:21:16 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ehf2-00045y-00; Fri, 31 Jan 2003 21:21:16 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: preservation of user information In-Reply-To: <5.2.0.9.0.20030131104954.01a044a8@127.0.0.1> References: <5.2.0.9.0.20030131104954.01a044a8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Fri, 31 Jan 2003 21:21:16 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >At 10:26 AM 1/31/2003, Hallvard B Furuseth wrote: >> Well, that has been shot down, but maybe this sentence in [Models] 6.1: >> >> Where such requirements have not be explicitly stated, servers SHOULD >> preserve the value of user information but MAY return the value in a >> different form. >> >> can be strengthened a little: Append >> >> ..."provided that the implementation documents possible divergences." > > Interoperability should not depend on the availability > of documentation of implementations. Interoperability? If an implementation modifies values without documenting that, you have the same interoperability as without that requirement. You just don't have a standard-conforming implementation. Or if you are thinking of X.500 gateways and things like that, where it's hard to say just what values will be changed, the implementation could just cop out by documenting that any values may change. My point was just that if documentation is required, users who need unchanged values for some particular attribute can at least know if an implementation provides what they want. Anyway, must rush. Off to vacation. For real, this time:-) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 15:58:31 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17316 for ; Fri, 31 Jan 2003 15:04:39 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VK3RAU051551; Fri, 31 Jan 2003 20:07:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VJx5cH051022; Fri, 31 Jan 2003 19:59:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 19:59:05 +0000 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VJx0AM051006 for ; Fri, 31 Jan 2003 19:59:01 GMT (envelope-from hbf@bombur.uio.no) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18ehJR-0004DN-00; Fri, 31 Jan 2003 20:58:57 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ehJR-00042x-00; Fri, 31 Jan 2003 20:58:57 +0100 From: Hallvard B Furuseth Message-Id: To: ietf-ldapbis@OpenLDAP.org Subject: Models: Schema references to undefined entities Date: Fri, 31 Jan 2003 20:58:57 +0100 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: In [Models], please specify whether the various schema elements may refer to OIDs of entities that are not defined in the schema. E.g. an objectclass with "MAY ()", an attribute type with an undefined syntax, a DIT content rule with an undefined objectclass in the "AUX" part, etc. Such undefined entities wouldn't be useful for anything in the directory, but it could be useful to allow them in the schema because a schema element could be defined without defining everything it depends on. For example, an attribute type defined by the server's standard setup may have to be omitted because of a name conflict with a locally defined attribute type. One could edit the attribute out of the object class which uses it as well, but that's uglier since clients would receive an incorrect definition of that object class. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 18:55:00 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22650 for ; Fri, 31 Jan 2003 18:54:59 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VNlAOW002043; Fri, 31 Jan 2003 23:57:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h0VNH6IL001051; Fri, 31 Jan 2003 23:17:06 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 31 Jan 2003 23:17:05 +0000 Received: from cantor.openldap.org (root@cantor.openldap.org [IPv6:2001:4f8:3:ba:206:29ff:fe1f:3f3e]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h0VNGsOY000924 for ; Fri, 31 Jan 2003 23:16:58 GMT (envelope-from michael@stroeder.com) Received: from nb2.stroeder.com (xviii.yapay.inka.de [193.197.184.146]) by cantor.openldap.org (8.12.6/8.12.6) with ESMTP id h0VLp17c030027 for ; Fri, 31 Jan 2003 21:51:08 GMT (envelope-from michael@stroeder.com) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 47CF921288 for ; Fri, 31 Jan 2003 22:24:49 +0100 (CET) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id E3A0D1C4C3 for ; Fri, 31 Jan 2003 22:24:47 +0100 (CET) Message-ID: <3E3AE99F.3090006@stroeder.com> Date: Fri, 31 Jan 2003 22:24:47 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Schema references to undefined entities References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallvard B Furuseth wrote: > In [Models], please specify whether the various schema elements > may refer to OIDs of entities that are not defined in the schema. Yes, this has to defined more clearly. > E.g. an objectclass with "MAY ()", an > attribute type with an undefined syntax, a DIT content rule with > an undefined objectclass in the "AUX" part, etc. Once I had a lengthy discussion with Kurt about some attribute types referencing missing syntax OIDs. We did not reach consensus about semantics. Kurt's claim was that e.g. a LDAP syntax can be 'partially supported' and hence not be listed in the sub schema sub entry. > Such undefined entities wouldn't be useful for anything in the > directory, but it could be useful to allow them in the schema > because a schema element could be defined without defining > everything it depends on. At least with LDAP syntaxes this seems to be common practice today. :-/ > For example, an attribute type defined > by the server's standard setup may have to be omitted because of > a name conflict with a locally defined attribute type. One could > edit the attribute out of the object class which uses it as well, > but that's uglier since clients would receive an incorrect > definition of that object class. If the object class references the attribute type by name isn't there still a naming conflict? IMHO the 'locally defined attribute type' gets referenced thus changing the object class definition. Maybe it's me but this sounds rather strange to me. Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 19:43:05 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23691 for ; Fri, 31 Jan 2003 19:43:04 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h110jjOM004010; Sat, 1 Feb 2003 00:45:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h110j7Co004001; Sat, 1 Feb 2003 00:45:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 1 Feb 2003 00:45:07 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h110j4OK003991 for ; Sat, 1 Feb 2003 00:45:04 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h110it8O065259; Sat, 1 Feb 2003 00:44:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030131162356.02939540@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Jan 2003 16:43:31 -0800 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: Models: Schema references to undefined entities Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3E3AE99F.3090006@stroeder.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h110j5OK003992 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 01:24 PM 1/31/2003, Michael Ströder wrote: >Hallvard B Furuseth wrote: >>In [Models], please specify whether the various schema elements >>may refer to OIDs of entities that are not defined in the schema. > >Yes, this has to defined more clearly. I don't believe there are any integrity requirements here. If fact, there are cases where a server may not know some schema descriptions (or choose not to publish some) even though they are referenced by other schema descriptions. Note that I use the term "published" here. Schema is "defined" in technical specifications, servers publish descriptions they know (if they so choose). Some servers may support schema modification, however this is beyond the scope of this document. (I believe there are/were individual submissions in this area.) >>E.g. an objectclass with "MAY ()", an >>attribute type with an undefined syntax, a DIT content rule with >>an undefined objectclass in the "AUX" part, etc. > >Once I had a lengthy discussion with Kurt about some attribute types referencing missing syntax OIDs. We did not reach consensus about semantics. The WG, I believe, reached consensus that servers publish what they know (if they so choose) and that publication of a particular description is not indication that the server has implemented the semantics associated with that described element. That is, publishing 'alias' does not imply the server supports aliases. The current I-D reflects this. >Kurt's claim was that e.g. a LDAP syntax can be 'partially supported' and hence not be listed in the sub schema sub entry. Yes. For example, a server might be able to generate values of a particular syntax but not be capable of accepting values of that syntax. >>Such undefined entities wouldn't be useful for anything in the >>directory, but it could be useful to allow them in the schema >>because a schema element could be defined without defining >>everything it depends on. > >At least with LDAP syntaxes this seems to be common practice today. :-/ > >>For example, an attribute type defined >>by the server's standard setup may have to be omitted because of a name conflict with a locally defined attribute type. One could >>edit the attribute out of the object class which uses it as well, >>but that's uglier since clients would receive an incorrect >>definition of that object class. > >If the object class references the attribute type by name isn't there still a naming conflict? IMHO the 'locally defined attribute type' gets referenced thus changing the object class definition. Maybe it's me but this sounds rather strange to me. From owner-ietf-ldapbis@OpenLDAP.org Fri Jan 31 20:03:09 2003 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24061 for ; Fri, 31 Jan 2003 20:03:09 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1115jOM004382; Sat, 1 Feb 2003 01:05:50 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.12.6/8.12.6/Submit) with SMTP id h110wCZQ004214; Sat, 1 Feb 2003 00:58:12 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 1 Feb 2003 00:58:12 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h110wAOK004204 for ; Sat, 1 Feb 2003 00:58:10 GMT (envelope-from Kurt@OpenLDAP.org) Received: from hobo.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.6) with ESMTP id h110w18O065327; Sat, 1 Feb 2003 00:58:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030131164345.029440f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Jan 2003 16:56:36 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: preservation of user information Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030131104954.01a044a8@127.0.0.1> <5.2.0.9.0.20030131104954.01a044a8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 12:21 PM 1/31/2003, Hallvard B Furuseth wrote: >My point was just that if documentation is required, To require a implementor to document their behavior implies that that another implementor must depend on this documentation to achieve interoperability. That is counter to the production of technical specifications intended to allow independent development of interoperable implementations. >Anyway, must rush. Off to vacation. For real, this time:-) Enjoy! Kurt