From owner-ietf-ldapbis@OpenLDAP.org Sat Feb 1 13:43: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 NAA14113 for ; Sat, 1 Feb 2003 13:43: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 h11Ik8OM034153; Sat, 1 Feb 2003 18:46:27 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 h11Iii1o034080; Sat, 1 Feb 2003 18:44:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 1 Feb 2003 18:44: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 h11IifOK034070 for ; Sat, 1 Feb 2003 18:44:42 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 h11IiW8O071729; Sat, 1 Feb 2003 18:44:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030201095717.029e6af8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 01 Feb 2003 10:43:06 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: structural subclass of auxiliary object class 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 11:57 AM 1/31/2003, Hallvard B Furuseth wrote: >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. Well, since the semantics of such an auxiliary class is not well defined in X.500, if someone is using such... they really should submit revisions to X.501 to define the desired semantics. Once they do that, someone can then adapt these revisions for use in LDAP. But until there are well defined semantics for which we can demonstrate multiple interoperable independently implementations of, we need to state that such is not allowed. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sat Feb 1 13:53: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 NAA14333 for ; Sat, 1 Feb 2003 13:53: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 h11ItjOM034719; Sat, 1 Feb 2003 18:55: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 h11IlLip034204; Sat, 1 Feb 2003 18:47:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sat, 1 Feb 2003 18:47:21 +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 h11IlIOK034194 for ; Sat, 1 Feb 2003 18:47:18 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 h11IlA8O071743; Sat, 1 Feb 2003 18:47:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030201104350.0292ee78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 01 Feb 2003 10:45:41 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Change of structural object class 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 11:57 AM 1/31/2003, Hallvard B Furuseth wrote: >[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. I don't consider these statements as being redundant. The first is describing the data model. The second says servers are responsible for ensuring this part of the model is adhered to. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 2 23:35: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 XAA18361 for ; Sun, 2 Feb 2003 23:35: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 h134aQOM073758; Mon, 3 Feb 2003 04:37: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 h134WEGW073685; Mon, 3 Feb 2003 04:32:14 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 3 Feb 2003 04:32:14 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h134WAOK073669 for ; Mon, 3 Feb 2003 04:32:11 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 19888 invoked from network); 3 Feb 2003 04:30:39 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 3 Feb 2003 04:30:39 -0000 Reply-To: From: "Steven Legg" To: "'Hallvard B Furuseth'" , Subject: RE: ORDERING rules vs. lessOrEqual filters Date: Mon, 3 Feb 2003 15:30:17 +1100 Message-ID: <000101c2cb3c$f497caa0$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.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. Strictly speaking, the assertion syntax for greaterOrEqual and lessOrEqual is determined by the equality matching rule. The assertionValue in AttributeValueAssertion is always an assertion value for the equality matching rule of the type, thought it isn't necessarily the equality rule that is applied. The protocol draft needs to be corrected. > > How? OK, a greaterOrEqual filter returns (not (result of the ORDERING > matching rule)). But how is a lessOrEqual filter evaluated? The obvious way, e.g. the filter (cn<=foo) is equivalent to: (|(cn:caseIgnoreOrderingMatch:=foo)(cn:caseIgnoreMatch:=foo)) > Does it > swap the assertion value and the attribute value, In general, it is not possible to swap the assertion value and attribute value since they may be of different syntaxes. > or must ORDERING > matching rules be implemented internally to return three values (less, > equal, greater) in addition to Undefined? An implementation is free to implement matching any way it wants as long as it exhibits the correct external behaviour. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 2 23:53: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 XAA18538 for ; Sun, 2 Feb 2003 23:53: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 h134twOM074153; Mon, 3 Feb 2003 04:55: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 h134nPZT074101; Mon, 3 Feb 2003 04:49:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 3 Feb 2003 04:49:25 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h134nLOK074089 for ; Mon, 3 Feb 2003 04:49:21 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 22623 invoked from network); 3 Feb 2003 04:47:51 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 3 Feb 2003 04:47:51 -0000 Reply-To: From: "Steven Legg" To: "'Hallvard B Furuseth'" , Subject: RE: How are approxMatch matching rules declared? Date: Mon, 3 Feb 2003 15:47:29 +1100 Message-ID: <000201c2cb3f$5be1fb70$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: > [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. That's because there are practically no matching rules defined which describe approximate matching semantics. For the most part, if such a field were defined there would be nothing with which to populate it. The semantics of an approximate match filter item have always been left to the discretion of the server implementations. > 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? In principle, every attribute type with an equality matching rule supports approximate matching though in practice it might not differ from the equality match. > Should [Models] say something about this? More likely the protocol draft since that is where the search operation is described. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 10:35: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 KAA12491 for ; Mon, 10 Feb 2003 10:35: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 h1AFapOM086725; Mon, 10 Feb 2003 15:37:55 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 h1AFa1uA086690; Mon, 10 Feb 2003 15:36:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 15:36:01 +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 h1AFZrOK086660; Mon, 10 Feb 2003 15:35:53 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 18iFyE-0007kI-00; Mon, 10 Feb 2003 16:35:46 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18iFyD-0003yV-00; Mon, 10 Feb 2003 16:35:45 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: "Kurt D. Zeilenga" Cc: Michael =?iso-8859-1?Q?Str=F6der?= , ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Schema references to undefined entities In-Reply-To: <5.2.0.9.0.20030131162356.02939540@127.0.0.1> References: <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030131162356.02939540@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Feb 2003 16:35:45 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id h1AFZsOK086661 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 Kurt D. Zeilenga writes: >At 01:24 PM 1/31/2003, Michael Ströder wrote: >>Hallvard B Furuseth wrote: > Note that I use the term "published" here. Schema is "defined" > in technical specifications, servers publish descriptions they > know (if they so choose). Oh, right. That was in a previous draft of [Models], but it's not in version 06. Could you put it back? >>> 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. Sorry, I forgot to mention that I thought of replacing the attribute's name, if any, with its OID in the object class description. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 11:30: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 LAA14621 for ; Mon, 10 Feb 2003 11:30: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 h1AGQ6OM090216; Mon, 10 Feb 2003 16:33: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 h1AGHqu0089761; Mon, 10 Feb 2003 16:17:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 16:17:52 +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 h1AGHiOK089728; Mon, 10 Feb 2003 16:17: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 18iGcl-0005fw-00; Mon, 10 Feb 2003 17:17:39 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18iGck-00044m-00; Mon, 10 Feb 2003 17:17:38 +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: Change of structural object class In-Reply-To: <5.2.0.9.0.20030201104350.0292ee78@127.0.0.1> References: <5.2.0.9.0.20030201104350.0292ee78@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Feb 2003 17:17:38 +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 don't consider these statements as being redundant. The first > is describing the data model. The second says servers are > responsible for ensuring this part of the model is adhered to. Aren't servers responsible for ensuring that all of the model is adhered to anyway? If not, I think they should be. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 11:43: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 LAA15087 for ; Mon, 10 Feb 2003 11:43: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 h1AGkEOM091158; Mon, 10 Feb 2003 16:46: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 h1AGiLTt091044; Mon, 10 Feb 2003 16:44:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 16:44:21 +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 h1AGiGOK091025 for ; Mon, 10 Feb 2003 16:44:17 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.6) with ESMTP id h1AGi88O042031; Mon, 10 Feb 2003 16:44:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210074930.01a0cec8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 08:41:52 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: subschema semantics (Was: Models: Schema references to undefined entities) Cc: Michael =?iso-8859-1?Q?Str=F6der?= , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030131162356.02939540@127.0.0.1> <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030131162356.02939540@127.0.0.1> 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 h1AGiHOK091036 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 title changed to separate issues At 07:35 AM 2/10/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 01:24 PM 1/31/2003, Michael Ströder wrote: >>>Hallvard B Furuseth wrote: > >> Note that I use the term "published" here. Schema is "defined" >> in technical specifications, servers publish descriptions they >> know (if they so choose). > >Oh, right. That was in a previous draft of [Models], but it's not in >version 06. Could you put it back? I assume you are asking to revert the I-D to "servers publish schema what they support" semantics. Last spring we had a discussion of these issues last spring. Here is the start of the thread: http://www.openldap.org/lists/ietf-ldapbis/200205/msg00034.html Steven Legg raised a concern about this http://www.openldap.org/lists/ietf-ldapbis/200206/msg00002.html which lead to the I-D having its current wording. I (as Editor) believe the current language in this area reflects WG consensus. Of course, the purpose of this WG Last Call is to confirm WG consensus. I suggest you review the above referenced messages as well as other messages you might find on this subject in the archives. After doing so, if you have concerns, make a specific suggestion (change X to Y) for the WG to consider. (I'll respond to rest of your post in a separate post) Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 12:23: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 MAA16728 for ; Mon, 10 Feb 2003 12:23: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 h1AHQ4OO093859; Mon, 10 Feb 2003 17:26: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 h1AHCJJR092576; Mon, 10 Feb 2003 17:12:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 17:12:19 +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 h1AHCFOK092566 for ; Mon, 10 Feb 2003 17:12:15 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.6) with ESMTP id h1AHC68O042225; Mon, 10 Feb 2003 17:12:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210084218.01a54958@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 09:09:50 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Change of structural object class Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030201104350.0292ee78@127.0.0.1> <5.2.0.9.0.20030201104350.0292ee78@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:17 AM 2/10/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> I don't consider these statements as being redundant. The first >> is describing the data model. The second says servers are >> responsible for ensuring this part of the model is adhered to. > >Aren't servers responsible for ensuring that all of the model is adhered >to anyway? Well I think LDAP servers MUST act in accordance with the X.500 model, I don't agree that they are responsible for ensuring all aspects of the model are adhered to. At some level, there will be "garbage in, garbage out" problem. The solution to that problem is at the client (which provides the garbage). Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 12:23:49 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 MAA16753 for ; Mon, 10 Feb 2003 12:23: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 h1AHQ4OQ093859; Mon, 10 Feb 2003 17:26: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 h1AHELTl092744; Mon, 10 Feb 2003 17:14:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 17:14:21 +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 h1AHEHOK092730 for ; Mon, 10 Feb 2003 17:14:17 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.6) with ESMTP id h1AHE98O042237; Mon, 10 Feb 2003 17:14:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210091001.01a16ce0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 09:11:53 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Schema references to undefined entities Cc: Michael =?iso-8859-1?Q?Str=F6der?= , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030131162356.02939540@127.0.0.1> <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030131162356.02939540@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:35 AM 2/10/2003, Hallvard B Furuseth wrote: >>>> 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. > >Sorry, I forgot to mention that I thought of replacing the attribute's >name, if any, with its OID in the object class description. I think this is just another facet of the "short names are ambiguous" issue. Does the current text, in particular 6.2, adequately address this issue? If not, what changes do you suggest? Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 15:45: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 PAA24879 for ; Mon, 10 Feb 2003 15:45: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 h1AKhvOM007904; Mon, 10 Feb 2003 20:47: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 h1AKTPSQ002696; Mon, 10 Feb 2003 20:29:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 20:29:25 +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 h1AKTLOK002684 for ; Mon, 10 Feb 2003 20:29:21 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.6) with ESMTP id h1AKTC8O044076; Mon, 10 Feb 2003 20:29:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 12:26:49 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <5.2.0.9.0.20030118110326.01a04220@127.0.0.1> 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: At 05:04 PM 1/17/2003, Kurt D. Zeilenga wrote: >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 I'm thinking that this SHOULD should be should as it appears to be a use requirement, not an implementation requirement. >> >>could get the addition >> >> except in contexts where the server cannot unambiguously determine >> which the represents. I note that the original imperative applied to all implementations (or was it uses?). Anyways, one could generalized the addition to: except where use of the form is ambigious. Which is, of course, often the case. Hence, I suggest replacing the PARAGRAPH with: While the form is generally preferred, the form should be used when an unambiguous short name (descriptor) is not available. See Section 6.2 for additional discussion of Short Names (descriptors). From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 16:05:44 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 QAA25844 for ; Mon, 10 Feb 2003 16:05: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 h1AKu4OY008774; Mon, 10 Feb 2003 21:08: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 h1AKrS1k008616; Mon, 10 Feb 2003 20:53:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 20:53:28 +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 h1AKrOOK008605 for ; Mon, 10 Feb 2003 20:53:24 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.6) with ESMTP id h1AKrG8O044321; Mon, 10 Feb 2003 20:53:16 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210124554.026989a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 12:50:53 -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: To address the alias RDN issues, I suggest adding the following paragraph and example to Section 2.6: Every 'alias' object class must also belongs to object classes which allow suitable naming attributes to be present. These object classes may be subclasses of 'alias' or auxiliary classes (including 'extensibleObject'). Example: dn: cn=bar,dc=example,dc=com objectClass: top objectClass: alias objectClass: extensibleObject cn: bar aliasedObjectName: cn=foo,dc=example,dc=com Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 16:07: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 QAA25925 for ; Mon, 10 Feb 2003 16:07: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 h1AKk4Ou008022; Mon, 10 Feb 2003 21:10: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 h1AKeUT1007734; Mon, 10 Feb 2003 20:40:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 20:40:30 +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 h1AKeLOK007706; Mon, 10 Feb 2003 20:40: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 18iKiw-0004lp-00; Mon, 10 Feb 2003 21:40:18 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18iKiw-0004gY-00; Mon, 10 Feb 2003 21:40:18 +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.20030210121802.01a5c210@127.0.0.1> 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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Mon, 10 Feb 2003 21:40: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: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: > Hence, I suggest replacing the PARAGRAPH with: > > While the form is generally preferred, the > form should be used when an unambiguous short name (descriptor) > is not available. See Section 6.2 for additional discussion > of Short Names (descriptors). I think something about which context the oid has is necessary. Naming context as well as as attribute type vs. object class. Otherwise people will be likely to think that if they only define one OID with name 'foo', the server doesn't need to know that 'foo' is an attribute type and not an object class. Sorry, it's too late now for me to come up with a good wording. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 16:37: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 QAA27014 for ; Mon, 10 Feb 2003 16:37: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 h1ALa6OQ011467; Mon, 10 Feb 2003 21:40: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 h1ALYkTS011424; Mon, 10 Feb 2003 21:34:46 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 21:34:46 +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 h1ALYgOK011415 for ; Mon, 10 Feb 2003 21:34:42 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.6) with ESMTP id h1ALYY8O044737; Mon, 10 Feb 2003 21:34:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210133032.02767b48@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 13:32:11 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: models: unnecessary numericoids 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: Looks like I (almost) missed this one... At 02:09 PM 1/30/2003, Hallvard B Furuseth wrote: >Suggestion: >The s in [Models] 4.1.4 (MatchingRuleUseDescription) >and 4.1.6 (DITContentRuleDescription) could be plain s, >the schema knows their names. I don't think that's a good enough reason to make the suggested change. If it ain't broke... Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 16:43: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 QAA27167 for ; Mon, 10 Feb 2003 16:43: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 h1ALk3Os012191; Mon, 10 Feb 2003 21:46: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 h1ALfK4s011921; Mon, 10 Feb 2003 21:41:20 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 21:41:20 +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 h1ALfGOK011911 for ; Mon, 10 Feb 2003 21:41: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.6) with ESMTP id h1ALf78O044826; Mon, 10 Feb 2003 21:41:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 13:38:44 -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.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@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:40 PM 2/10/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> Hence, I suggest replacing the PARAGRAPH with: >> >> While the form is generally preferred, the >> form should be used when an unambiguous short name (descriptor) >> is not available. See Section 6.2 for additional discussion >> of Short Names (descriptors). > >I think something about which context the oid has is necessary. >Naming context as well as as attribute type vs. object class. >Otherwise people will be likely to think that if they only define >one OID with name 'foo', the server doesn't need to know that >'foo' is an attribute type and not an object class. >Sorry, it's too late now for me to come up with a good wording. Isn't this more appropriately covered in 6.2? (And as a follow-up: Is this covered appropriately in 6.2?) Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 16:53: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 QAA27507 for ; Mon, 10 Feb 2003 16:53: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 h1ALu5OM013191; Mon, 10 Feb 2003 21:56: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 h1ALpZcs013037; Mon, 10 Feb 2003 21:51:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 21:51: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 h1ALpVOK013026 for ; Mon, 10 Feb 2003 21:51:31 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.6) with ESMTP id h1ALpM8O044993; Mon, 10 Feb 2003 21:51:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 13:48:59 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses 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 02:34 PM 1/30/2003, Hallvard B Furuseth wrote: >[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)". Such an addition could be viewed as calling for the publication of non-extensible matching rules in matching rule use attribute. The matching rule use attribute publishes those type/rules combinations which can used in assertions of the form (type:rule:=value). Whether the rule can be used in other contexts (such as an equality rule for a type) is not relevant here. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 18:00: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 SAA29437 for ; Mon, 10 Feb 2003 18:00: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 h1AMQIP0014214; Mon, 10 Feb 2003 23:03:16 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 h1AMPPAN014193; Mon, 10 Feb 2003 22:25:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 22:25: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 h1AMPKOK014183 for ; Mon, 10 Feb 2003 22:25:20 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.6) with ESMTP id h1AMPB8O045195 for ; Mon, 10 Feb 2003 22:25:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210125617.01a0bec8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 14:22:48 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Summary of [Models] issues from WG Last Call 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: Here is a list of issues raised and my (as editor) suggested resolution. 1) objectIdentifierMatch on ambiguous name http://www.openldap.org/lists/ietf-ldapbis/200301/msg00044.html Replace last paragraph of 1.3 with: While the form is generally preferred, the form should be used when an unambiguous short name (descriptor) is not available. See Section 6.2 for additional discussion of Short Names (descriptors). 2) Naming Contexts (and Models: naming contexts and the root DSE) http://www.openldap.org/lists/ietf-ldapbis/200301/msg00053.html 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. 3) Structural Object Class (and governingStructureRule) http://www.openldap.org/lists/ietf-ldapbis/200301/msg00055.html Request to LDAP descriptions of 'structuralObjectClass' and, subsequently, 'governingStructureRule' descriptions. Beyond scope. No action. (Note: author considers the lack of these descriptions a technical omission and will re-raise issue at a more appropriate time.) 4) Subclassing (attribute list inheritance) http://www.openldap.org/lists/ietf-ldapbis/200301/msg00057.html It was requested that Section 2.4 be clarified as to effects of subclassing on MUST/MAY lists. As Section 2.4 already includes the statement As an entry of a class must meet the requirements of each class it belongs to, it can be said that an object class inherits the sets of allowed and required attributes from its superclasses. No action. 5) Subclassing (additional subclassing imperatives) http://www.openldap.org/lists/ietf-ldapbis/200301/msg00057.html It was noted that Section 2.4.2 and 2.4.3 includes restrictions up subclassing not explicitly stated in X.501. The author considers the lack of such statements in X.501 as a technical omission as such subclassing makes little sense. No action. 6) aliases http://www.openldap.org/lists/ietf-ldapbis/200301/msg00075.html Clarification was requested regarding whether naming attributes of an alias entry must be present in the alias entry and, if so, what schema mechanism allows them to be present. The following clarification and example are to be added: 7) preservation of user information http://www.openldap.org/lists/ietf-ldapbis/200301/msg00078.html A request was made to change the value preservation requirement to bit perfect. The current requirement is believed to be technically sound and is supported by consensus. No action. 8) unnecessary numericoids http://www.openldap.org/lists/ietf-ldapbis/200301/msg00080.html A request was made to change to in a number of productions as the form is already known. The current approach is not "broken". No action. 9) matching rule uses http://www.openldap.org/lists/ietf-ldapbis/200301/msg00083.html Request to add comment to 4.1.4. Comment may confuse implementors. No action. 10) Approx Matching rules http://www.openldap.org/lists/ietf-ldapbis/200301/msg00099.html Request to extend Attribute Types to include explicit specification of approximate matching rule. X.500 uses implication specification. No action. 11) Schema references to undefined entries http://www.openldap.org/lists/ietf-ldapbis/200301/msg00110.html Request to clarify whether published schema needs to be complete. Add to 4.2: "LDAP clients SHOULD NOT assume a published subschema is complete." 12) DIT Content Rules and AUX object classes http://www.openldap.org/lists/ietf-ldapbis/200301/msg00103.html Request to add support for a mechanism to specification of a DIT content rule to allow any auxiliary class. Beyond scope. No action. 13) Change of Structural Object Class http://www.openldap.org/lists/ietf-ldapbis/200301/msg00111.html Request to remove statements considered redundant. No action. 14) Subschema Semantics http://www.openldap.org/lists/ietf-ldapbis/200302/msg00008.html Request to change subschema semantics from "publish what you know" to "publish what you support". Consensus believed to support current semantics. No action. Please let the WG know (within the next few days) if I've missed any issue or if you disagree with the suggested action so that Bob can declare consensus (or lack thereof). Kurt (as Editor) From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 18:21: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 SAA29963 for ; Mon, 10 Feb 2003 18:21: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 h1ANG4PE018395; Mon, 10 Feb 2003 23:24: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 h1AN4JDD017305; Mon, 10 Feb 2003 23:04:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 23:04:19 +0000 Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1AN4COK017268; Mon, 10 Feb 2003 23:04:12 GMT (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1AN4BFR022888; Mon, 10 Feb 2003 15:04:11 -0800 Received: from D-140-142-21-81.dhcp4.washington.edu (D-140-142-21-81.dhcp4.washington.edu [140.142.21.81]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1AN4BFl026558 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 10 Feb 2003 15:04:11 -0800 Date: Mon, 10 Feb 2003 15:04:10 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: "Kurt D. Zeilenga" cc: IETF ldapbis WG Subject: Re: Summary of [Models] issues from WG Last Call In-Reply-To: <5.2.0.9.0.20030210125617.01a0bec8@127.0.0.1> 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 Mon, 10 Feb 2003, Kurt D. Zeilenga wrote: > Please let the WG know (within the next few days) if I've missed any > issue or if you disagree with the suggested action so that Bob can > declare consensus (or lack thereof). Thanks, Kurt. Note that I'm on vacation 2003-02-13 thru 2003-02-24, so any official action on my part that doesn't happen in the next couple of days will have to wait until after the 24th. - RL "Bob" From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 18:21: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 SAA29977 for ; Mon, 10 Feb 2003 18:21: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 h1ANG4PC018395; Mon, 10 Feb 2003 23:24: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 h1ANBQY6018118; Mon, 10 Feb 2003 23:11:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 10 Feb 2003 23:11:26 +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 h1ANBMOK018106 for ; Mon, 10 Feb 2003 23:11:22 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.6) with ESMTP id h1ANBE8O046984 for ; Mon, 10 Feb 2003 23:11:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030210150734.027597a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 15:08:50 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: alias (was: Summary of [Models] issues from WG Last Call) In-Reply-To: <5.2.0.9.0.20030210125617.01a0bec8@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:22 PM 2/10/2003, Kurt D. Zeilenga wrote: >6) aliases > http://www.openldap.org/lists/ietf-ldapbis/200301/msg00075.html > > Clarification was requested regarding whether naming attributes > of an alias entry must be present in the alias entry and, if so, > what schema mechanism allows them to be present. The following > clarification and example are to be added: Every 'alias' object class must also belongs to object classes which allow suitable naming attributes to be present. These object classes may be subclasses of 'alias' or auxiliary classes (including 'extensibleObject'). Example: dn: cn=bar,dc=example,dc=com objectClass: top objectClass: alias objectClass: extensibleObject cn: bar aliasedObjectName: cn=foo,dc=example,dc=com sorry, Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 10 19:23:54 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 TAA02100 for ; Mon, 10 Feb 2003 19:23: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 h1B0QROM027139; Tue, 11 Feb 2003 00:26: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 h1B0KO4T024496; Tue, 11 Feb 2003 00:20:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 11 Feb 2003 00:20:24 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h1B0KJOK024445 for ; Tue, 11 Feb 2003 00:20:20 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 11313 invoked from network); 11 Feb 2003 00:17:55 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 11 Feb 2003 00:17:55 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" , Subject: RE: alias (was: Summary of [Models] issues from WG Last Call) Date: Tue, 11 Feb 2003 11:18:23 +1100 Message-ID: <001301c2d163$17d1ad20$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.20030210150734.027597a8@127.0.0.1> Importance: Normal 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: > At 02:22 PM 2/10/2003, Kurt D. Zeilenga wrote: > >6) aliases > > http://www.openldap.org/lists/ietf-ldapbis/200301/msg00075.html > > > > Clarification was requested regarding whether naming attributes > > of an alias entry must be present in the alias entry and, if so, > > what schema mechanism allows them to be present. The following > > clarification and example are to be added: > > Every 'alias' object class must also belongs to object > classes which allow suitable naming attributes to be > present. A more accurate wording would be: An entry with the 'alias' object class must also belong to an object class (or classes), or be governed by a content rule, which allows suitable naming attributes to be present. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 11 08:13: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 IAA03648 for ; Tue, 11 Feb 2003 08: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 h1BDGFOM060131; Tue, 11 Feb 2003 13:16: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 h1BDAtqd059803; Tue, 11 Feb 2003 13:10:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 11 Feb 2003 13:10:55 +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 h1BDAfOK059722; Tue, 11 Feb 2003 13:10:42 GMT (envelope-from jmcmeek@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1BDAKx7079676; Tue, 11 Feb 2003 08:10:20 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.52]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1BDAIs0033220; Tue, 11 Feb 2003 08:10:18 -0500 Subject: Re: Summary of [Models] issues from WG Last Call To: "Kurt D. Zeilenga" 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: Tue, 11 Feb 2003 07:10:17 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V601_01192003|January 19, 2003) at 02/11/2003 07:10:19 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: With Steven's and Kurt's corrections to item 6 (aliases), this looks good to me. John McMeeking From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 11 11:54: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 LAA11285 for ; Tue, 11 Feb 2003 11:54:17 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1BGuOOM078377; Tue, 11 Feb 2003 16:57: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 h1BGlbtQ077535; Tue, 11 Feb 2003 16:47:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 11 Feb 2003 16:47:37 +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 h1BGlWOK077522 for ; Tue, 11 Feb 2003 16:47:32 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.6) with ESMTP id h1BGlJ8O052517; Tue, 11 Feb 2003 16:47:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030211084325.01a338d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 11 Feb 2003 08:45:51 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: alias (was: Summary of [Models] issues from WG Last Call) Cc: In-Reply-To: <001301c2d163$17d1ad20$a518200a@osmium.mtwav.adacel.com.au> References: <5.2.0.9.0.20030210150734.027597a8@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 04:18 PM 2/10/2003, Steven Legg wrote: >A more accurate wording would be: > > An entry with the 'alias' object class must also belong to > an object class (or classes), or be governed by a content rule, > which allows suitable naming attributes to be present. This wording is much better than mine. It should be used instead. Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 11 17:53: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 RAA20831 for ; Tue, 11 Feb 2003 17:53:57 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1BMuLOM099276; Tue, 11 Feb 2003 22:56:44 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 h1BMsArs099212; Tue, 11 Feb 2003 22:54:10 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 11 Feb 2003 22:54: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 h1BMrwOK099187; Tue, 11 Feb 2003 22:54:02 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 18ijHn-0000Iq-00; Tue, 11 Feb 2003 23:53:55 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18ijHm-0000Wf-00; Tue, 11 Feb 2003 23:53: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: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> References: <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 11 Feb 2003 23:53: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: >At 12:40 PM 2/10/2003, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>> Hence, I suggest replacing the PARAGRAPH with: >>> >>> While the form is generally preferred, the >>> form should be used when an unambiguous short name (descriptor) >>> is not available. See Section 6.2 for additional discussion >>> of Short Names (descriptors). >> >>I think something about which context the oid has is necessary. >>Naming context as well as as attribute type vs. object class. >>Otherwise people will be likely to think that if they only define >>one OID with name 'foo', the server doesn't need to know that >>'foo' is an attribute type and not an object class. >>Sorry, it's too late now for me to come up with a good wording. > > Isn't this more appropriately covered in 6.2? Maybe. But wouldn't you just end up restating and expanding "the form should be used..." part? Something like "Short names may only be used in contexts where the server can unambiguously translate them to numeric OIDs and knows what kind of entity the OID represents (i.e. whether it represents an object class, an attribute type, or something else.)" > (And as a follow-up: Is this covered appropriately in 6.2?) I can't see that it's covered at all. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 11 20:33: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 UAA24310 for ; Tue, 11 Feb 2003 20:33: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 h1C1aAOM012172; Wed, 12 Feb 2003 01:36: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 h1C1V30r011782; Wed, 12 Feb 2003 01:31:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 01:31:03 +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 h1C1UxOK011762 for ; Wed, 12 Feb 2003 01:30:59 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.6) with ESMTP id h1C1Up8O056462; Wed, 12 Feb 2003 01:30:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 11 Feb 2003 17:29:21 -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.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@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:53 PM 2/11/2003, Hallvard B Furuseth wrote: >> Isn't this more appropriately covered in 6.2? > >Maybe. But wouldn't you just end up restating and expanding "the > form should be used..." part? The problem is making statements in 1.3 is that it is intended to be referenced by many specifications and any statement we make here may not be appropriate for all cases. So, even if we have to restate and expand in 6.2, that's the approach I prefer. >Something like > >"Short names may only be used in contexts where the server can >unambiguously translate them to numeric OIDs and knows what kind of >entity the OID represents (i.e. whether it represents an object class, >an attribute type, or something else.)" > >> (And as a follow-up: Is this covered appropriately in 6.2?) > >I can't see that it's covered at all. Fair enough. How about adding before the paragraph starting with Procedures for registering short names (descriptors) ... the paragraph: Implementations SHOULD avoid the use of registered short names (descriptors) or, when not available, an object identifiers in numeric form, to avoid ambiguity. From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 09:26: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 JAA03525 for ; Wed, 12 Feb 2003 09:26: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 h1CEQNOM040300; Wed, 12 Feb 2003 14:27: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 h1CEGcPS039971; Wed, 12 Feb 2003 14:16:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 14:16:38 +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 h1CEGXOK039962 for ; Wed, 12 Feb 2003 14:16:34 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.6) with ESMTP id h1CEGP8O060312 for ; Wed, 12 Feb 2003 14:16:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030212061344.023fce88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 06:14:55 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: objectIdentifierMatch on ambiguous name In-Reply-To: <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> References: <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@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:29 PM 2/11/2003, I wrote: >How about adding before the paragraph starting with > Procedures for registering short names (descriptors) ... > >the paragraph: > Implementations SHOULD avoid the use of registered > short names (descriptors) or, when not available, > an object identifiers in numeric form, to avoid > ambiguity. s/avoid the// Sorry. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 14:54: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 OAA13690 for ; Wed, 12 Feb 2003 14:54: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 h1CJu8OQ065793; Wed, 12 Feb 2003 19:57: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 h1CJqrnW065547; Wed, 12 Feb 2003 19:52:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 19:52:53 +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 h1CJqmOK065503; Wed, 12 Feb 2003 19:52:48 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 18j2vz-0000ae-00; Wed, 12 Feb 2003 20:52:43 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j2vz-0003S4-00; Wed, 12 Feb 2003 20:52:43 +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.20030212061344.023fce88@127.0.0.1> References: <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> <5.2.0.9.0.20030212061344.023fce88@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 20:52:43 +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 05:29 PM 2/11/2003, I wrote: >> Implementations SHOULD avoid the use of registered >> short names (descriptors) or, when not available, >> an object identifiers in numeric form, to avoid >> ambiguity. I prefer my own text. Yours doesn't imply that attribute type ( ... NAME 'oid' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID from the start of this thread may not contain short names, like you and others have said in previous articles. > s/avoid the// s/use of/use/ -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 15:53: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 PAA15444 for ; Wed, 12 Feb 2003 15:53: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 h1CKu7OO072245; Wed, 12 Feb 2003 20:56: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 h1CKrc0D072152; Wed, 12 Feb 2003 20:53:38 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 20:53:38 +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 h1CKrWOK072132 for ; Wed, 12 Feb 2003 20:53:32 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.6) with ESMTP id h1CKrN8O063558; Wed, 12 Feb 2003 20:53:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030212122738.02451800@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 12:51:54 -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.20030212061344.023fce88@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> <5.2.0.9.0.20030212061344.023fce88@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:52 AM 2/12/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 05:29 PM 2/11/2003, I wrote: >>> Implementations SHOULD avoid the use of registered >>> short names (descriptors) or, when not available, >>> an object identifiers in numeric form, to avoid >>> ambiguity. > >I prefer my own text. I think I was addressing a different issue. I think something more is needed. Likely [Syntaxes, 4.3.26] needs to say something, as well as [Models]. [Syntaxes] likely should say that the form may only be used in contexts which specifically detail which short names are applicable. As this is a common issue with the use of the production, I think it might actually be appropriate to say something about it in the [Models, 1.3]. >Yours doesn't imply that > attribute type ( ... NAME 'oid' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID >from the start of this thread may not contain short names, >like you and others have said in previous articles. Well, actually, if 'oid' was an operational attribute it could be defined such that short names could be used. For userApplications attributes (excepting objectClass), short names cannot be used as the server has no knowledge of the user application semantics. (I'm going to review past posts before offerring any additional suggestions.) Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 16:13: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 QAA15786 for ; Wed, 12 Feb 2003 16:13: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 h1CLG7OO073165; Wed, 12 Feb 2003 21:16: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 h1CL8p5Z072900; Wed, 12 Feb 2003 21:08:51 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 21:08:51 +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 h1CL8gOK072871; Wed, 12 Feb 2003 21:08:43 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 18j47S-0002NR-00; Wed, 12 Feb 2003 22:08:38 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j47S-0003ce-00; Wed, 12 Feb 2003 22:08:38 +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.20030212122738.02451800@127.0.0.1> References: <5.2.0.9.0.20030212061344.023fce88@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> <5.2.0.9.0.20030212122738.02451800@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 22:08:38 +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 I was addressing a different issue. I think > something more is needed. Likely [Syntaxes, 4.3.26] needs > to say something, as well as [Models]. Also [Syntaxes] 5.2.16 (objectIdentifierFirstComponentMatch) and maybe 5.2.17 (objectIdentifierMatch). Except for that, I agree. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 16:33: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 QAA16420 for ; Wed, 12 Feb 2003 16:33: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 h1CLa7Oa073918; Wed, 12 Feb 2003 21:36:30 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 h1CLRNt2073604; Wed, 12 Feb 2003 21:27:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 21:27:23 +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 h1CLRKOK073594 for ; Wed, 12 Feb 2003 21:27:21 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.6) with ESMTP id h1CLRC8O063762; Wed, 12 Feb 2003 21:27:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030212132146.02521150@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 13:25:42 -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.20030212122738.02451800@127.0.0.1> <5.2.0.9.0.20030212061344.023fce88@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> <5.2.0.9.0.20030212122738.02451800@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: Okay, taking this on somewhat incrementally. How about we replace the last paragraph of 1.3 (leaving my previous addition to 6.2 in place) the following? While the form is generally preferred, the form should be used when an unambiguous short name (descriptor) is not available. When the form is used, the representation SHALL be considered invalid if the implementation cannot determine unambiguously which object identifier the refers to. See Section 6.2 for additional discussion of Short Names (descriptors). Does this cover your [Models] concerns? Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 16:33: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 QAA16443 for ; Wed, 12 Feb 2003 16:33: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 h1CLa7OY073918; Wed, 12 Feb 2003 21:36: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 h1CLSqqY073665; Wed, 12 Feb 2003 21:28:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 21:28:52 +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 h1CLSlOK073638; Wed, 12 Feb 2003 21:28: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 18j4Qp-0002kJ-00; Wed, 12 Feb 2003 22:28:39 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j4Qn-0003fP-00; Wed, 12 Feb 2003 22:28:37 +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: Michael =?iso-8859-1?Q?Str=F6der?= , ietf-ldapbis@OpenLDAP.org Subject: Re: subschema semantics (Was: Models: Schema references to undefined entities) In-Reply-To: <5.2.0.9.0.20030210074930.01a0cec8@127.0.0.1> References: <5.2.0.9.0.20030131162356.02939540@127.0.0.1> <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030210074930.01a0cec8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 22:28:37 +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 assume you are asking to revert the I-D to "servers publish > schema what they support" semantics. No, this part of 4.4 (Subschema Discovery), which disappeared at the same time. Sorry, I should have tracked it down before posting: Clients SHOULD NOT assume that server supports all referenced elements of a particular definition. For example, a client is not to assume the server supports the EQUALITY matching rule of a listed attribute unless the server publishes a definition for that matching rule. It doesn't quite fit the messages below, though. > Last spring we had a discussion of these issues last spring. > Here is the start of the thread: > http://www.openldap.org/lists/ietf-ldapbis/200205/msg00034.html > > Steven Legg raised a concern about this > http://www.openldap.org/lists/ietf-ldapbis/200206/msg00002.html > > which lead to the I-D having its current wording. I (as Editor) > believe the current language in this area reflects WG consensus. > Of course, the purpose of this WG Last Call is to confirm WG > consensus. I suggest you review the above referenced messages > as well as other messages you might find on this subject in the > archives. After doing so, if you have concerns, make a specific > suggestion (change X to Y) for the WG to consider. My concern, in light of that discussion, is that the current text can lead a reader to assume that if a server only publishes schema elements it supports. If I understand that discussion correctly, adding this to 4.4 should cover it: Clients SHOULD NOT assume that server supports all published or referenced elements of a particular definition. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 17:03:54 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 RAA17306 for ; Wed, 12 Feb 2003 17:03: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 h1CM67OS075336; Wed, 12 Feb 2003 22:06:44 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 h1CLwqtZ075022; Wed, 12 Feb 2003 21:58:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 21:58:52 +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 h1CLwlOK074995; Wed, 12 Feb 2003 21:58: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 18j4tw-00040v-00; Wed, 12 Feb 2003 22:58:44 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j4tw-0003kS-00; Wed, 12 Feb 2003 22:58:44 +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: Matching Rule Uses In-Reply-To: <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> References: <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 22:58:44 +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 02:34 PM 1/30/2003, Hallvard B Furuseth wrote: >>[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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I just noticed: I think that should be "an extensibleMatch filter". I can't find a definition of what extensible matching rules are. Should have noticed that after Ron Ramsay's response. >> Please add something like "(in addition to those uses expressed in >> AttributeType descriptions)". > > Such an addition could be viewed as calling for the > publication of non-extensible matching rules in matching rule use > attribute. OK, how about: "extensibleMatch filters can also use matching rules from an attribute type's AttributeType description." At least that's what you said in a private mail earlier. Or if I misundersood, add an explicit note about the opposite instead. > Whether the rule can be used in other contexts (such > as an equality rule for a type) is not relevant here. True, but that's not what I'm talking about. Also, am I right in assuming that a matching rule use may only list attributes with a syntax which satisfies the restrictions specified in the matching rule defintion in [Syntaxes] 5.2.*? If not, something needs to be said about what these restrictions mean. Finally, it must be specified which attributes a Matching Rule may be used with if it has no corresponding Matching Rule Use. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 17:04: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 RAA17320 for ; Wed, 12 Feb 2003 17:04: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 h1CM67OU075336; Wed, 12 Feb 2003 22:06: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 h1CM2TUw075184; Wed, 12 Feb 2003 22:02:29 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 22:02:29 +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 h1CM2OOK075155; Wed, 12 Feb 2003 22:02:25 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 18j4xR-0000F9-00; Wed, 12 Feb 2003 23:02:21 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j4xQ-0003kq-00; Wed, 12 Feb 2003 23:02:20 +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: DIT Content Rules and AUX object classes In-Reply-To: <5.2.0.9.0.20030131102420.01a0e050@127.0.0.1> References: <5.2.0.9.0.20030131102420.01a0e050@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 23:02:20 +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: >> 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. Well, I only wanted that if 'no AUX' meant 'all aux classes allowed'. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 17:13: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 RAA17508 for ; Wed, 12 Feb 2003 17:13: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 h1CMG7Oa076071; Wed, 12 Feb 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 h1CMC1xJ075854; Wed, 12 Feb 2003 22:12:01 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 22:12:01 +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 h1CMBuOK075806; Wed, 12 Feb 2003 22:11:57 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 18j56c-0001EV-00; Wed, 12 Feb 2003 23:11:50 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j56c-0003mV-00; Wed, 12 Feb 2003 23:11:50 +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: Michael =?iso-8859-1?Q?Str=F6der?= , ietf-ldapbis@OpenLDAP.org Subject: Re: subschema semantics (Was: Models: Schema references to undefined entities) In-Reply-To: <5.2.0.9.0.20030212135259.02535d38@127.0.0.1> References: <5.2.0.9.0.20030210074930.01a0cec8@127.0.0.1> <5.2.0.9.0.20030131162356.02939540@127.0.0.1> <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030212135259.02535d38@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 23:11:50 +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 dropping the 4.2 addition suggestion (I > made in the summary (item 11) and instead add the > following to 4.4? > > Clients SHOULD NOT assume a published subschema is > complete nor assume the server supports all schema > elements it publishes. Fine. (I'd prefer 'publishes or references', but that's no big deal.) -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 17:13: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 RAA17522 for ; Wed, 12 Feb 2003 17:13: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 h1CMG7OY076071; Wed, 12 Feb 2003 22:16: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 h1CMAFgF075685; Wed, 12 Feb 2003 22:10:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 22:10: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 h1CMADOK075673 for ; Wed, 12 Feb 2003 22:10:13 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.6) with ESMTP id h1CMA48O064207; Wed, 12 Feb 2003 22:10:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030212135259.02535d38@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 14:08:34 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: subschema semantics (Was: Models: Schema references to undefined entities) Cc: Michael =?iso-8859-1?Q?Str=F6der?= , ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030210074930.01a0cec8@127.0.0.1> <5.2.0.9.0.20030131162356.02939540@127.0.0.1> <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030210074930.01a0cec8@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:28 PM 2/12/2003, Hallvard B Furuseth wrote: > Clients SHOULD NOT assume that server supports all published or > referenced elements of a particular definition. How about dropping the 4.2 addition suggestion (I made in the summary (item 11) and instead add the following to 4.4? Clients SHOULD NOT assume a published subschema is complete nor assume the server supports all schema elements it publishes. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 17:14: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 RAA17538 for ; Wed, 12 Feb 2003 17:14: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 h1CMG7OW076071; Wed, 12 Feb 2003 22:16: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 h1CMEPW3075978; Wed, 12 Feb 2003 22:14:25 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 22:14:25 +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 h1CMELOK075940; Wed, 12 Feb 2003 22:14: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 18j58y-0001Vp-00; Wed, 12 Feb 2003 23:14:16 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j58y-0003md-00; Wed, 12 Feb 2003 23:14: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: Michael =?iso-8859-1?Q?Str=F6der?= , ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Schema references to undefined entities In-Reply-To: <5.2.0.9.0.20030210091001.01a16ce0@127.0.0.1> References: <5.2.0.9.0.20030131162356.02939540@127.0.0.1> <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030210091001.01a16ce0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 23:14: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 07:35 AM 2/10/2003, Hallvard B Furuseth wrote: >>>>> 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. >> >> Sorry, I forgot to mention that I thought of replacing the attribute's >> name, if any, with its OID in the object class description. > > I think this is just another facet of the "short names are > ambiguous" issue. Does the current text, in particular 6.2, > adequately address this issue? If not, what changes do you > suggest? None. I wasn't talking about changes in the drafts here, but how to change the text of the object class description in a server without changing its semantics. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 17:25: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 QAA16419 for ; Wed, 12 Feb 2003 16:33: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 h1CLa7Oc073918; Wed, 12 Feb 2003 21:36: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 h1CLZXqP073895; Wed, 12 Feb 2003 21:35:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 21:35:32 +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 h1CLZROK073846; Wed, 12 Feb 2003 21:35:28 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 18j4XM-0005R0-00; Wed, 12 Feb 2003 22:35:24 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18j4XL-0003gV-00; Wed, 12 Feb 2003 22:35:23 +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.20030212132146.02521150@127.0.0.1> References: <5.2.0.9.0.20030212122738.02451800@127.0.0.1> <5.2.0.9.0.20030212061344.023fce88@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> <5.2.0.9.0.20030212132146.02521150@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 12 Feb 2003 22:35: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: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: > Okay, taking this on somewhat incrementally. How about > we replace the last paragraph of 1.3 (leaving my previous > addition to 6.2 in place) the following? > > While the form is generally preferred, the > form should be used when an unambiguous short name (descriptor) is > not available. When the form is used, the representation > SHALL be considered invalid if the implementation cannot determine > unambiguously which object identifier the refers to. > > See Section 6.2 for additional discussion of Short Names (descriptors). > > Does this cover your [Models] concerns? Sorry, no. It still needs an addition like: "...or cannot know kind of entity the OID represents (i.e. whether it represents an object class, an attribute type, or something else.)" Otherwise the reader may consider 'oid: person' to be unambiguous if he has a person object class and no other OID named 'person', with my previous definition of attribute 'oid'. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 18:44: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 SAA19011 for ; Wed, 12 Feb 2003 18:44: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 h1CNk7OO079852; Wed, 12 Feb 2003 23:46:40 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 h1CNdLRN079619; Wed, 12 Feb 2003 23:39:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 12 Feb 2003 23:39:21 +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 h1CNdFOK079609 for ; Wed, 12 Feb 2003 23:39: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.6) with ESMTP id h1CNd68O064893; Wed, 12 Feb 2003 23:39:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 15:37:37 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@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:58 PM 2/12/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 02:34 PM 1/30/2003, Hallvard B Furuseth wrote: >>>[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 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I just noticed: I think that should be "an extensibleMatch filter". >I can't find a definition of what extensible matching rules are. >Should have noticed that after Ron Ramsay's response. I concur. >>> Please add something like "(in addition to those uses expressed in >>> AttributeType descriptions)". >> >> Such an addition could be viewed as calling for the >> publication of non-extensible matching rules in matching rule use >> attribute. > >OK, how about: > > "extensibleMatch filters can also use matching rules from an > attribute type's AttributeType description." I don't think that's correct. Listing a rule in an attribute type description doesn't imply that rule can be used in an extensibleMatch filter. >At least that's what you said in a private mail earlier. Or if >I misundersood, add an explicit note about the opposite instead. I could have been confused... I can think of a number of possible opposites, but none make sense to me. Please clarify. >> Whether the rule can be used in other contexts (such >> as an equality rule for a type) is not relevant here. > >True, but that's not what I'm talking about. > >Also, am I right in assuming that a matching rule use may only >list attributes with a syntax which satisfies the restrictions >specified in the matching rule defintion in [Syntaxes] 5.2.*? >If not, something needs to be said about what these restrictions >mean. I'm not sure which restrictions you refer to here. Can you be more specific? >Finally, it must be specified which attributes a Matching Rule >may be used with if it has no corresponding Matching Rule Use. Not publishing a rule use (or any schema element) only means the server doesn't know that use (or isn't willing to let you know it knows that use). Maybe 4.4 addition we previously discussed should say: Clients SHOULD NOT assume a published subschema is complete nor assume the server supports all of the schema elements it publishes nor assume the server does not support any elements it did not publish. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 12 19:23: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 TAA19571 for ; Wed, 12 Feb 2003 19:23: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 h1D0Q7OO080835; Thu, 13 Feb 2003 00:26:45 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 h1D0JZ4W080738; Thu, 13 Feb 2003 00:19:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 00:19: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 h1D0JTOK080728 for ; Thu, 13 Feb 2003 00:19:29 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.6) with ESMTP id h1D0JK8O065114; Thu, 13 Feb 2003 00:19:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030212161529.0242e668@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 16:17:51 -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.20030212132146.02521150@127.0.0.1> <5.2.0.9.0.20030212122738.02451800@127.0.0.1> <5.2.0.9.0.20030212061344.023fce88@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> <5.2.0.9.0.20030212132146.02521150@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:35 PM 2/12/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> Okay, taking this on somewhat incrementally. How about >> we replace the last paragraph of 1.3 (leaving my previous >> addition to 6.2 in place) the following? >> Does this cover your [Models] concerns? > >Sorry, no. How about? While the form is generally preferred when the usage is restricted to short names referring to object identifiers which identify like kinds of objects (e.g., attribute type descriptions, matching rule descriptions, object class descriptions), the form should be used when the object identifiers may identify multiple kinds of objects or when unambiguous short name (descriptor) is not available. When the form is used, the representation SHALL be considered invalid if the usage is not restricted as discussed above or the implementation cannot determine unambiguously which object identifier the refers to. From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 02:34: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 CAA06353 for ; Thu, 13 Feb 2003 02:34: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 h1D7a8OS096242; Thu, 13 Feb 2003 07:37: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 h1D7ZXKO096222; Thu, 13 Feb 2003 07:35:33 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 07:35: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 h1D7ZPOK096192; Thu, 13 Feb 2003 07:35:26 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 18jDty-0002S8-00; Thu, 13 Feb 2003 08:35:22 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18jDty-0005Jb-00; Thu, 13 Feb 2003 08:35:22 +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.20030212161529.0242e668@127.0.0.1> References: <5.2.0.9.0.20030212132146.02521150@127.0.0.1> <5.2.0.9.0.20030212122738.02451800@127.0.0.1> <5.2.0.9.0.20030212061344.023fce88@127.0.0.1> <5.2.0.9.0.20030210133220.0276c098@127.0.0.1> <5.2.0.9.0.20030210121802.01a5c210@127.0.0.1> <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.20030118110326.01a04220@127.0.0.1> <5.2.0.9.0.20030211165224.01a057f0@127.0.0.1> <5.2.0.9.0.20030212161529.0242e668@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 13 Feb 2003 08:35:22 +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: >> Sorry, no. > > How about? (...) Fine. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 02:44: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 CAA06508 for ; Thu, 13 Feb 2003 02:44: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 h1D7k8OO096650; Thu, 13 Feb 2003 07:46: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 h1D7gQPg096556; Thu, 13 Feb 2003 07:42:26 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 07:42:26 +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 h1D7gLOK096527; Thu, 13 Feb 2003 07:42:22 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 18jE0e-0003vS-00; Thu, 13 Feb 2003 08:42:16 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18jE0e-0005Kx-00; Thu, 13 Feb 2003 08:42: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: Matching Rule Uses In-Reply-To: <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> References: <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 13 Feb 2003 08:42: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: >> "extensibleMatch filters can also use matching rules from an >> attribute type's AttributeType description." > > I don't think that's correct. Listing a rule in > an attribute type description doesn't imply that > rule can be used in an extensibleMatch filter. > >> At least that's what you said in a private mail earlier. Or if >> I misundersood, add an explicit note about the opposite instead. > > I could have been confused... > > I can think of a number of possible opposites, but none > make sense to me. Please clarify. Never mind for now. I think the discussion below will cover it. >> Also, am I right in assuming that a matching rule use may only >> list attributes with a syntax which satisfies the restrictions >> specified in the matching rule defintion in [Syntaxes] 5.2.*? >> If not, something needs to be said about what these restrictions >> mean. > > I'm not sure which restrictions you refer to here. Can you > be more specific? Example: [Syntaxes] 5.2.3 caseIgnoreIA5Match says: The caseIgnoreIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g the IA5 String syntax) whose corresponding ASN.1 type is IA5String. So caseIgnoreIA5Match can be used with attributes whose corresponding ASN.1 type is IA5String, but not e.g. bit string syntax. I'm hoping that this also means that a caseIgnoreIA5Match matching rule use can only list attributes whose corresponding ASN.1 type is IA5String. >> Finally, it must be specified which attributes a Matching Rule >> may be used with if it has no corresponding Matching Rule Use. > > Not publishing a rule use (or any schema element) > only means the server doesn't know that use (or isn't willing > to let you know it knows that use). > > Maybe 4.4 addition we previously discussed should say: > Clients SHOULD NOT assume a published subschema is complete nor > assume the server supports all of the schema elements it publishes > nor assume the server does not support any elements it did not publish. Heh. It gets complicated, but I guess that's the right text. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 04:08: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 EAA07607 for ; Thu, 13 Feb 2003 04:08:57 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1D8u8Om099770; Thu, 13 Feb 2003 09:11: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 h1D8tto5099762; Thu, 13 Feb 2003 08:55:55 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 08:55:55 +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 h1D8trOK099752 for ; Thu, 13 Feb 2003 08:55:53 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.6) with ESMTP id h1D8ti8O067796; Thu, 13 Feb 2003 08:55:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213002006.02469580@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 00:54:14 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@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:42 PM 2/12/2003, Hallvard B Furuseth wrote: >Example: [Syntaxes] 5.2.3 caseIgnoreIA5Match says: > > The caseIgnoreIA5Match rule compares an assertion value of the IA5 > String syntax to an attribute value of a syntax (e.g the IA5 String > syntax) whose corresponding ASN.1 type is IA5String. This wording, I think, is overly restrictive. It's not necessary for the assertion value here to be an IA5String or even contain an IA5String. What is necessary is a well-defined algorithm for performing the assertion against a value of the attribute type's syntax. >So caseIgnoreIA5Match can be used with attributes whose corresponding >ASN.1 type is IA5String, but not e.g. bit string syntax. I'm hoping >that this also means that a caseIgnoreIA5Match matching rule use can >only list attributes whose corresponding ASN.1 type is IA5String. No, the assertion syntax and attribute value syntax can be quite different. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 04:29: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 EAA07967 for ; Thu, 13 Feb 2003 04:29: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 h1D9Q8Om002178; Thu, 13 Feb 2003 09:32: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 h1D9HjjG001712; Thu, 13 Feb 2003 09:17:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 09:17:45 +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 h1D9HfOK001677; Thu, 13 Feb 2003 09:17:41 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 18jFUv-0000iP-00; Thu, 13 Feb 2003 10:17:37 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18jFUv-0005XU-00; Thu, 13 Feb 2003 10:17:37 +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: Matching Rule Uses In-Reply-To: <5.2.0.9.0.20030213002006.02469580@127.0.0.1> References: <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030213002006.02469580@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 13 Feb 2003 10:17:37 +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 11:42 PM 2/12/2003, Hallvard B Furuseth wrote: >> So caseIgnoreIA5Match can be used with attributes whose corresponding >> ASN.1 type is IA5String, but not e.g. bit string syntax. I'm hoping >> that this also means that a caseIgnoreIA5Match matching rule use can >> only list attributes whose corresponding ASN.1 type is IA5String. > > No, the assertion syntax and attribute value syntax can be quite > different. Well, the point is that if it may be a syntax which is not permitted by the restrictions I quoted from [Syntaxes], or whatever they are modified to say, that must be mentioned in [Models]. -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 05:50: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 FAA09032 for ; Thu, 13 Feb 2003 05:50: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 h1DAkFOk007947; Thu, 13 Feb 2003 10:53: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 h1DAUa2m007282; Thu, 13 Feb 2003 10:30:36 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 10:30:36 +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 h1DAUROK007253; Thu, 13 Feb 2003 10:30:31 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 18jGdK-0007as-00; Thu, 13 Feb 2003 11:30:22 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18jGdK-0005jR-00; Thu, 13 Feb 2003 11:30:22 +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: Summary of [Models] issues from WG Last Call In-Reply-To: <5.2.0.9.0.20030210125617.01a0bec8@127.0.0.1> References: <5.2.0.9.0.20030210125617.01a0bec8@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 13 Feb 2003 11:30:22 +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: > Please let the WG know (within the next few days) if I've missed > any issue This one. Couldn't find it in the archive: >From: Hallvard B Furuseth >Message-Id: >Date: Mon, 10 Feb 2003 16:29:26 +0100 >Subject: Re: Models: Detail with Object Class Definitions > >Kurt D. Zeilenga writes: >>At 02:42 PM 1/30/2003, Hallvard B Furuseth wrote: >>> I suggest the following addition to [Models] 4.1.1 (Object >>> Class Definitions): >>> >>> "Note that the MUST and MAY lists may be modified by DIT >>> Content Rules (see 4.1.6)." >> >> I think that might actually lead to confusion as one might >> think that the DIT content rule is "modifying" the object >> class definition. > > True. How about > > "Note that which attributes MAY and MUST be present in an > entry is also affected by DIT Content Rules (see 4.1.6)." -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 10:47: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 KAA16034 for ; Thu, 13 Feb 2003 10:47: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 h1DFk9Oa030172; Thu, 13 Feb 2003 15:49: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 h1DFdIik029705; Thu, 13 Feb 2003 15:39:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 15:39:18 +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 h1DFdFOK029693 for ; Thu, 13 Feb 2003 15:39:15 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.6) with ESMTP id h1DFd78O070321; Thu, 13 Feb 2003 15:39:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213072106.01a06528@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 07:37:36 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Summary of [Models] issues from WG Last Call Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030210125617.01a0bec8@127.0.0.1> <5.2.0.9.0.20030210125617.01a0bec8@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:30 AM 2/13/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> Please let the WG know (within the next few days) if I've missed >> any issue > >This one. Couldn't find it in the archive: > >>From: Hallvard B Furuseth >>Message-Id: >>Date: Mon, 10 Feb 2003 16:29:26 +0100 >>Subject: Re: Models: Detail with Object Class Definitions >> >>Kurt D. Zeilenga writes: >>>At 02:42 PM 1/30/2003, Hallvard B Furuseth wrote: >>>> I suggest the following addition to [Models] 4.1.1 (Object >>>> Class Definitions): >>>> >>>> "Note that the MUST and MAY lists may be modified by DIT >>>> Content Rules (see 4.1.6)." >>> >>> I think that might actually lead to confusion as one might >>> think that the DIT content rule is "modifying" the object >>> class definition. >> >> True. How about >> >> "Note that which attributes MAY and MUST be present in an >> entry is also affected by DIT Content Rules (see 4.1.6)." I think that the statements in Section 2.4: - regulating, in conjunction with DIT content rule specifications, the attributes that are contained in entries; and Section 2.4.2: - the structural object class of an entry is used, along with an associated DIT content rule, to control the content of an entry and Section 4: c) DIT Content Rule definitions that extend the specification of allowable attributes for entries beyond those indicated by the structural object classes of the entries; as well as those in Section 4.1.6 are quite sufficient. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 10:53:24 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 KAA16177 for ; Thu, 13 Feb 2003 10:53: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 h1DFu9OO031221; Thu, 13 Feb 2003 15:56: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 h1DFlbcG030230; Thu, 13 Feb 2003 15:47:37 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 15:47:37 +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 h1DFlZOK030214 for ; Thu, 13 Feb 2003 15:47:35 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.6) with ESMTP id h1DFlQ8O070392; Thu, 13 Feb 2003 15:47:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213073744.01a08b08@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 07:45:56 -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: References: <5.2.0.9.0.20030131102420.01a0e050@127.0.0.1> <5.2.0.9.0.20030131102420.01a0e050@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:02 PM 2/12/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>> 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. > >Well, I only wanted that if 'no AUX' meant 'all aux classes allowed'. In re-examining this issue, I think it might be appropriate to add to Section 2.4.3. The DIT content rule associated with the structural object class of the entry controls which auxiliary classes the entry may belong to. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 11:13: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 LAA16474 for ; Thu, 13 Feb 2003 11:13: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 h1DGGUOO033037; Thu, 13 Feb 2003 16:16: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 h1DFuLat031243; Thu, 13 Feb 2003 15:56:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 15:56:21 +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 h1DFuIOK031232 for ; Thu, 13 Feb 2003 15:56:18 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.6) with ESMTP id h1DFuA8O070515; Thu, 13 Feb 2003 15:56:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213060322.0247fb10@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 07:54:39 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030213002006.02469580@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030213002006.02469580@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:17 AM 2/13/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 11:42 PM 2/12/2003, Hallvard B Furuseth wrote: >>> So caseIgnoreIA5Match can be used with attributes whose corresponding >>> ASN.1 type is IA5String, but not e.g. bit string syntax. I'm hoping >>> that this also means that a caseIgnoreIA5Match matching rule use can >>> only list attributes whose corresponding ASN.1 type is IA5String. >> >> No, the assertion syntax and attribute value syntax can be quite >> different. > >Well, the point is that if it may be a syntax which is not permitted by >the restrictions I quoted from [Syntaxes], or whatever they are modified >to say, that must be mentioned in [Models]. The data model places no restrictions on the specification of matching rules in this area. Can you offer a specific change to [Models] which attempts to address your concern? Thanks, Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 13:36: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 NAA21484 for ; Thu, 13 Feb 2003 13:36: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 h1DIa9OO049091; Thu, 13 Feb 2003 18:39: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 h1DIZmrb048983; Thu, 13 Feb 2003 18:35:48 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 18:35:48 +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 h1DIZjOK048963 for ; Thu, 13 Feb 2003 18:35:45 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.6) with ESMTP id h1DIZa8O072646; Thu, 13 Feb 2003 18:35:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213100907.025564f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 10:34:06 -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: <5.2.0.9.0.20030213073744.01a08b08@127.0.0.1> References: <5.2.0.9.0.20030131102420.01a0e050@127.0.0.1> <5.2.0.9.0.20030131102420.01a0e050@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: In chatting with Hallvard offline about which auxiliary classes are allowed in an entry when there is no DIT content rule associated with the structural object class of an entry, I find that additional clarification is needed in this area. Hence, I suggest replacing Section 2.4.3 (Auxiliary Object Classes) with: Auxiliary object classes are used augment the characteristics of entries. They are commonly used to augment the sets of attributes required and allowed attributes to be present in an entry. They can be used to describe entries or classes of entries. Auxiliary object classes cannot subclass structural object classes. An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with structural object class of the entry. If no DIT content rule is associated with the structural object class of the entry, the entry cannot belong to any auxiliary object class. The set of auxiliary object classes which an entry belongs to can change over time. This, I believe, is fully consistent with X.501(93) which all LDAP servers MUST act in accordance with. I note that I, in general, view discussions of what servers which don't act in accordance with X.500 beyond the scope of the document. If a service doesn't implement DIT content rules, it can take any approach which is consistent with the models. They could either disallow auxiliary classes, they could could allow auxiliary classes (as if they had content rules which allowed all auxiliary classes for all structural object classes, or take some other approach. (As I noted in another thread, how do lightly act in accordance with X.500 might make a good Informational RFC.) Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 14:13:54 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 OAA22497 for ; Thu, 13 Feb 2003 14: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 h1DJG9OO051587; Thu, 13 Feb 2003 19:16: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 h1DJ77Zd051139; Thu, 13 Feb 2003 19:07:07 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 19:07: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 h1DJ74OK051129 for ; Thu, 13 Feb 2003 19:07: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.6) with ESMTP id h1DJ6u8O072976; Thu, 13 Feb 2003 19:06:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213104900.0254bf30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 11:05:25 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: References: <5.2.0.9.0.20030213060322.0247fb10@127.0.0.1> <5.2.0.9.0.20030213002006.02469580@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030213060322.0247fb10@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 10:08 AM 2/13/2003, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >>At 01:17 AM 2/13/2003, Hallvard B Furuseth wrote: >>> Well, the point is that if it may be a syntax which is not permitted by >>> the restrictions I quoted from [Syntaxes], or whatever they are modified >>> to say, that must be mentioned in [Models]. >> >> The data model places no restrictions on the specification >> of matching rules in this area. >> >> Can you offer a specific change to [Models] which attempts >> to address your concern? > >If there are no restrictions, The directory models place no restrictions on what kinds of matching rules can be defined, but a matching rule certainly is only (well-)defined for use with specific attribute value syntaxes. A server may publish any matching rule use it knows as being defined. >that would be: > >4.1.4: > "An attribute type can appear in a matching rule use even > if the corresponding matching rule definition in [Syntaxes] > does not allow the attribute type's syntax." Just like rules listed in the attribute type description, rules listed in matching rule use are listed when appropriate per the technical specification of the attribute type, its syntax, and the matching rule. >I might note that this is _not_ how OpenLDAP works now. >That creates e.g. a matchingRuleUse for caseIgnoreMatch >which does not allow seeAlso, which has a different syntax. Yes, because there is no specification is known by the server which details the use of caseIgnoreMatch against attribute values of distinguished name syntax. But if such specification were to come into existence and be known by the server, then the server could publish it if it so chooses. >Furthermore, > "If a matching rule has no corresponding matching rule use," > ..."it can be used with any attribute type."? > ...or if not, when can it be used? A matching rule can be used in an extensbleMatch search filter any time the usage is well-defined. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 14:52: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 OAA23453 for ; Thu, 13 Feb 2003 14:52: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 h1DIQ9Ou047182; Thu, 13 Feb 2003 18:33: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 h1DI8N9Q045513; Thu, 13 Feb 2003 18:08:23 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 18:08:23 +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 h1DI8HOK045449; Thu, 13 Feb 2003 18:08:18 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 18jNmN-0000kQ-00; Thu, 13 Feb 2003 19:08:11 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18jNmN-0006pp-00; Thu, 13 Feb 2003 19:08:11 +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: Matching Rule Uses In-Reply-To: <5.2.0.9.0.20030213060322.0247fb10@127.0.0.1> References: <5.2.0.9.0.20030213002006.02469580@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030213060322.0247fb10@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 13 Feb 2003 19:08:11 +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 01:17 AM 2/13/2003, Hallvard B Furuseth wrote: >> Well, the point is that if it may be a syntax which is not permitted by >> the restrictions I quoted from [Syntaxes], or whatever they are modified >> to say, that must be mentioned in [Models]. > > The data model places no restrictions on the specification > of matching rules in this area. > > Can you offer a specific change to [Models] which attempts > to address your concern? If there are no restrictions, that would be: 4.1.4: "An attribute type can appear in a matching rule use even if the corresponding matching rule definition in [Syntaxes] does not allow the attribute type's syntax." I might note that this is _not_ how OpenLDAP works now. That creates e.g. a matchingRuleUse for caseIgnoreMatch which does not allow seeAlso, which has a different syntax. Furthermore, "If a matching rule has no corresponding matching rule use," ..."it can be used with any attribute type."? ...or if not, when can it be used? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 15:19: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 PAA25706 for ; Thu, 13 Feb 2003 15:19:17 -0500 (EST) Received: from galois.openldap.org (smmsp@localhost [IPv6:::1]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1DKGEOW054580; Thu, 13 Feb 2003 20:21:44 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 h1DKA5AZ054170; Thu, 13 Feb 2003 20:10:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 20:10:05 +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 h1DKA0OK054095; Thu, 13 Feb 2003 20:10:01 GMT (envelope-from Chris.Oliva@entrust.com) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <1T4X4VTW>; Thu, 13 Feb 2003 15:09:24 -0500 Message-ID: From: Christopher Oliva To: "'Kurt D. Zeilenga'" , ietf-ldapbis@OpenLDAP.org Subject: RE: Summary of [Models] issues from WG Last Call Date: Thu, 13 Feb 2003 15:09:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D39B.C9F6EDF0" 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_01C2D39B.C9F6EDF0 Content-Type: text/plain > 7) preservation of user information > http://www.openldap.org/lists/ietf-ldapbis/200301/msg00078.html > A request was made to change the value preservation requirement > to bit perfect. The current requirement is believed to be > technically sound and is supported by consensus. No action. I'd like to clarify that I did not intend to advocate bit perfect storage of values (unless this is required by the syntax definition). I understand the server may need to transliterate value encodings for one reason or another. The current text in models allows a server to use the equality matching rule to validate that the new encoded value is equivalent to the original encoded value after transliteration. My main concern is that the equality matching rule may not always be adequately strong enough for this purpose. An example of this problem is the caseIgnoreMatch matching rule. This would allow the server to change the case of string values. This changes more than just the encoding of the value - the abstract value is changed as well. In this example, my belief is that the intent of choosing that equality matching rule was limited to comparison of value assertions (to identify duplicate values or searching for values) - but was not intended to allow the server to substitute "equivalent" values. My original proposal was intended to modify the text to say that although value encodings may be modified, the abstract value itself cannot be changed. However, if there is a need to have text that tells a server how to validate values after transliterations, I suggest adding a table that identifies a suitable matching rule for each syntax (or role that into the syntax definition in which case the DirectoryString syntax text should be updated). Chris. ------_=_NextPart_001_01C2D39B.C9F6EDF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of [Models] issues from WG Last Call

> 7) preservation of user information
>    http://www.openldap.org/lists/ietf-ldapbis/200301/msg0= 0078.html
>    A request was made to change = the value preservation requirement
>    to bit perfect.  The = current requirement is believed to be
>    technically sound and is = supported by consensus.  No action.

I'd like to clarify that I did not intend to advocate = bit perfect storage of values (unless this is required by the syntax = definition).

I understand the server may need to transliterate = value encodings for one reason or another. The current text in models = allows a server to use the equality matching rule to validate that the = new encoded value is equivalent to the original encoded value after = transliteration.

My main concern is that the equality matching rule = may not always be adequately strong enough for this purpose. An example = of this problem is the caseIgnoreMatch matching rule. This would allow = the server to change the case of string values. This changes more than = just the encoding of the value - the abstract value is changed as = well.

In this example, my belief is that the intent of = choosing that equality matching rule was limited to comparison of value = assertions (to identify duplicate values or searching for values) - but = was not intended to allow the server to substitute = "equivalent" values.

My original proposal was intended to modify the text = to say that although value encodings may be modified, the abstract = value itself cannot be changed. However, if there is a need to have = text that tells a server how to validate values after transliterations, = I suggest adding a table that identifies a suitable matching rule for = each syntax (or role that into the syntax definition in which case the = DirectoryString syntax text should be updated).

Chris.

------_=_NextPart_001_01C2D39B.C9F6EDF0-- From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 17:24: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 RAA13485 for ; Thu, 13 Feb 2003 17:24: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 h1DMQ9OS066404; Thu, 13 Feb 2003 22:26: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 h1DMM3j2066213; Thu, 13 Feb 2003 22:22:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 13 Feb 2003 22:22:02 +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 h1DMM0OK066199 for ; Thu, 13 Feb 2003 22:22:00 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.6) with ESMTP id h1DMLn8O074362; Thu, 13 Feb 2003 22:21:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213132718.0246e910@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 14:20:18 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: Summary of [Models] issues from WG Last Call 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 12:09 PM 2/13/2003, Christopher Oliva wrote: >My original proposal was intended to modify the text to say that although value encodings may be modified, the abstract value itself cannot be changed. So, you are proposing transliteration would be disallowed. I believe the consensus of the WG is that transliteration should continue to be allowed. >However, if there is a need to have text that tells a server how to validate values after transliterations, I suggest adding a table that identifies a suitable matching rule for each syntax (or role that into the syntax definition in which case the DirectoryString syntax text should be updated). Except for stating a general minimum requirement, what you propose is what the current approach offers: per syntax value preservation rules. As you don't appear to be arguing that general minimum is too loose, I don't see how your table suggestion changes any of the implementation requirements. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 19:23:44 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 TAA24163 for ; Thu, 13 Feb 2003 19:23: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 h1E0QAOO074247; Fri, 14 Feb 2003 00:26: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 h1E0HUaK072200; Fri, 14 Feb 2003 00:17:30 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 00:17:30 +0000 Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1E0HOOK072157; Fri, 14 Feb 2003 00:17:24 GMT (envelope-from d.w.chadwick@salford.ac.uk) Received: from salford.ac.uk ([80.5.217.212]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030214001721.EERZ22267.mta01-svc.ntlworld.com@salford.ac.uk>; Fri, 14 Feb 2003 00:17:21 +0000 Message-ID: <3E4C35D8.811BE468@salford.ac.uk> Date: Fri, 14 Feb 2003 00:18:32 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Matching Rule Uses References: <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030213002006.02469580@127.0.0.1> Content-Type: multipart/mixed; boundary="------------3B5A2FAE53F0C56B70A90C03" 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. --------------3B5A2FAE53F0C56B70A90C03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 11:42 PM 2/12/2003, Hallvard B Furuseth wrote: > >Example: [Syntaxes] 5.2.3 caseIgnoreIA5Match says: > > > > The caseIgnoreIA5Match rule compares an assertion value of the IA5 > > String syntax to an attribute value of a syntax (e.g the IA5 String > > syntax) whose corresponding ASN.1 type is IA5String. > > This wording, I think, is overly restrictive. It's not necessary > for the assertion value here to be an IA5String or even contain an > IA5String. What is necessary is a well-defined algorithm for > performing the assertion against a value of the attribute type's > syntax. I disagree. If you have a well defined algorithm, say Katakana to ASCII, then you should have a new matching rule for this, called KatakanaIA5 matching rule, and describe the algorithm in this new rule. The IA5 matching rule should be purely for IA5 strings, as per the existing definition. > > >So caseIgnoreIA5Match can be used with attributes whose corresponding > >ASN.1 type is IA5String, but not e.g. bit string syntax. I'm hoping > >that this also means that a caseIgnoreIA5Match matching rule use can > >only list attributes whose corresponding ASN.1 type is IA5String. > > No, the assertion syntax and attribute value syntax can be quite > different. Currently this is not so. They can be different, but only if the assertion syntax is a subtype of the attribute value syntax e.g, you can have an assertion syntax in IA5, for an attribute value syntax that is a sequence of things with a string as the first component (as in string first component match), or in IA5 for an attribute value of directory string (which can be a range of different character sets) David > > Kurt -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 01484 532930 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------3B5A2FAE53F0C56B70A90C03 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------3B5A2FAE53F0C56B70A90C03-- From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 20:13:29 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 UAA25106 for ; Thu, 13 Feb 2003 20:13: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 h1E1GAOO077608; Fri, 14 Feb 2003 01:16: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 h1E198Kj077528; Fri, 14 Feb 2003 01:09:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 01:09:08 +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 h1E196OK077518 for ; Fri, 14 Feb 2003 01:09:06 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.6) with ESMTP id h1E18v8O077660; Fri, 14 Feb 2003 01:08:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213163115.0248bea8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 17:07:26 -0800 To: David Chadwick From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses Cc: Hallvard B Furuseth , ietf-ldapbis@OpenLDAP.org In-Reply-To: <3E4C35D8.811BE468@salford.ac.uk> References: <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> <5.2.0.9.0.20030213002006.02469580@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 04:18 PM 2/13/2003, David Chadwick wrote: >> >So caseIgnoreIA5Match can be used with attributes whose corresponding >> >ASN.1 type is IA5String, but not e.g. bit string syntax. I'm hoping >> >that this also means that a caseIgnoreIA5Match matching rule use can >> >only list attributes whose corresponding ASN.1 type is IA5String. >> >> No, the assertion syntax and attribute value syntax can be quite >> different. > >Currently this is not so. X.501(93) does not restrict how "different" the syntaxes might be. It only requires that there be "rules for deriving a value of the assertion syntax from a value of the attribute syntax, if required." And while X.501 says these rules are to be defined as part of the matching rule specification, I believe (as is the common practice) that new syntax specifications may define new value derivation rules such that existing matching rules may be re-used with the new syntax. There are a wide variety of uses of the "core" matching rules with attribute value syntaxes not considered by the "core" specification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 23:40: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 XAA29960 for ; Thu, 13 Feb 2003 23:40: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 h1E4aAOU005983; Fri, 14 Feb 2003 04:42:45 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 h1E4TWqI005704; Fri, 14 Feb 2003 04:29:32 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 04:29:32 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h1E4TSOK005642 for ; Fri, 14 Feb 2003 04:29:29 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 4941 invoked from network); 14 Feb 2003 04:29:03 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 14 Feb 2003 04:29:03 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Models: Matching Rule Uses Date: Fri, 14 Feb 2003 15:27:29 +1100 Message-ID: <003101c2d3e1$6306d650$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <5.2.0.9.0.20030213163115.0248bea8@127.0.0.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: Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > At 04:18 PM 2/13/2003, David Chadwick wrote: > >> >So caseIgnoreIA5Match can be used with attributes whose > corresponding > >> >ASN.1 type is IA5String, but not e.g. bit string syntax. > I'm hoping > >> >that this also means that a caseIgnoreIA5Match matching > rule use can > >> >only list attributes whose corresponding ASN.1 type is IA5String. > >> > >> No, the assertion syntax and attribute value syntax can be quite > >> different. > > > >Currently this is not so. > > X.501(93) does not restrict how "different" the syntaxes might > be. It only requires that there be "rules for deriving a value of > the assertion syntax from a value of the attribute syntax, if > required." > > And while X.501 says these rules are to be defined as part of > the matching > rule specification, I believe (as is the common practice) > that new syntax > specifications may define new value derivation rules such > that existing > matching rules may be re-used with the new syntax. While there has been some tweaking of the X.500 string matching rules over time (because of changes to the Directory String syntax), I believe that the common practice in the X.500 universe is to define new matching rules for new syntaxes that don't fall within the set of specified applicable syntaxes of existing matching rules. Note that for some matching rules the set of applicable syntaxes is open-ended (e.g. objectIdentifierFirstComponentMatch applies to any existing syntax and any future syntax that is a SEQUENCE with an OBJECT IDENTIFER as its first component). Abuses of the X.500 model are all too common in the LDAP universe. Regards, Steven > > There are a wide variety of uses of the "core" matching rules > with attribute > value syntaxes not considered by the "core" specification. > > Kurt > > From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 13 23:47: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 XAA00136 for ; Thu, 13 Feb 2003 23:47: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 h1E4kAOO006860; Fri, 14 Feb 2003 04:49: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 h1E4j8CU006735; Fri, 14 Feb 2003 04:45:08 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 04:45:08 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h1E4j4OK006673 for ; Fri, 14 Feb 2003 04:45:05 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 6616 invoked from network); 14 Feb 2003 04:44:44 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 14 Feb 2003 04:44:44 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Models: Matching Rule Uses Date: Fri, 14 Feb 2003 15:43:09 +1100 Message-ID: <003401c2d3e3$93bc3fe0$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <5.2.0.9.0.20030213002006.02469580@127.0.0.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: Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > At 11:42 PM 2/12/2003, Hallvard B Furuseth wrote: > >Example: [Syntaxes] 5.2.3 caseIgnoreIA5Match says: > > > > The caseIgnoreIA5Match rule compares an assertion value of the IA5 > > String syntax to an attribute value of a syntax (e.g the > IA5 String > > syntax) whose corresponding ASN.1 type is IA5String. > > This wording, I think, is overly restrictive. For this rule in particular, or as an example ? > It's not necessary > for the assertion value here to be an IA5String or even contain an > IA5String. The matching rule definition requires the *assertion* syntax to be of the IA5 String syntax. Perhaps you mean't the *attribute* syntax of an attribute to which the rule is applied ? Regards, Steven > What is necessary is a well-defined algorithm for > performing the assertion against a value of the attribute type's > syntax. > > >So caseIgnoreIA5Match can be used with attributes whose corresponding > >ASN.1 type is IA5String, but not e.g. bit string syntax. I'm hoping > >that this also means that a caseIgnoreIA5Match matching rule use can > >only list attributes whose corresponding ASN.1 type is IA5String. > > No, the assertion syntax and attribute value syntax can be quite > different. > > Kurt > > From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 14 01:13: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 BAA01366 for ; Fri, 14 Feb 2003 01:13: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 h1E6GAOO010067; Fri, 14 Feb 2003 06:16: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 h1E66jVp009879; Fri, 14 Feb 2003 06:06:45 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 06:06:45 +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 h1E66hOK009869 for ; Fri, 14 Feb 2003 06:06: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.6) with ESMTP id h1E66V8O079515; Fri, 14 Feb 2003 06:06:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213213348.025b2be0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 22:05:00 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: Models: Matching Rule Uses Cc: In-Reply-To: <003401c2d3e3$93bc3fe0$a518200a@osmium.mtwav.adacel.com.au> References: <5.2.0.9.0.20030213002006.02469580@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:43 PM 2/13/2003, Steven Legg wrote: >For this rule in particular, or as an example ? I think I'll reserve myself and say the langauge is fine. So, returning to Hallvard's [Models] issue: >Example: [Syntaxes] 5.2.3 caseIgnoreIA5Match says: > > The caseIgnoreIA5Match rule compares an assertion value of the IA5 > String syntax to an attribute value of a syntax (e.g the IA5 String > syntax) whose corresponding ASN.1 type is IA5String. > >So caseIgnoreIA5Match can be used with attributes whose corresponding >ASN.1 type is IA5String, but not e.g. bit string syntax. As specified here, yes. But this specification can be revised (by update or extension) to support matching against attribute values of other syntaxes. >I'm hoping that this also means that a caseIgnoreIA5Match >matching rule use can only list attributes whose corresponding >ASN.1 type is IA5String. If the implementation has knowledge of an revised specification allowing other uses, it may publish them. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 14 01:23: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 BAA01551 for ; Fri, 14 Feb 2003 01:23: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 h1E6QAOO010334; Fri, 14 Feb 2003 06:26: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 h1E6IrKD010175; Fri, 14 Feb 2003 06:18:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 06:18: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 h1E6IlOK010163 for ; Fri, 14 Feb 2003 06:18:51 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.6) with ESMTP id h1E6Id8O079549 for ; Fri, 14 Feb 2003 06:18:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030213221015.025a9338@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 22:17:08 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: subschema semantics (Was: Models: Schema references to undefined entities) In-Reply-To: References: <5.2.0.9.0.20030212135259.02535d38@127.0.0.1> <5.2.0.9.0.20030210074930.01a0cec8@127.0.0.1> <5.2.0.9.0.20030131162356.02939540@127.0.0.1> <3E3AE99F.3090006@stroeder.com> <5.2.0.9.0.20030212135259.02535d38@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: The [Models, Section 4.2.5] sentence: This attribute holds definitions of LDAP syntaxes supported in the subschema. is not aligned with the position that server publishes what it knows, not what it supports. A number of other subschema attributes sections have similar sentences. I suggest deleting all occurrences of the phrase "supported in the subschema" in the I-D. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 14 08:07: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 IAA21619 for ; Fri, 14 Feb 2003 08:07: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 h1ED6BOO034831; Fri, 14 Feb 2003 13:10: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 h1ECvZmP034496; Fri, 14 Feb 2003 12:57:35 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 12:57:35 +0000 Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1ECvTOK034469; Fri, 14 Feb 2003 12:57:29 GMT (envelope-from d.w.chadwick@salford.ac.uk) Received: from salford.ac.uk ([80.5.217.212]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030214125722.ZLFE4022.mta06-svc.ntlworld.com@salford.ac.uk>; Fri, 14 Feb 2003 12:57:22 +0000 Message-ID: <3E4CE7FF.76C303E9@salford.ac.uk> Date: Fri, 14 Feb 2003 12:58:39 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Hallvard B Furuseth , ietf-ldapbis@OpenLDAP.org Subject: Re: Models: Matching Rule Uses References: <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@127.0.0.1> Content-Type: multipart/mixed; boundary="------------B55D95A7437ACE3431650453" 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. --------------B55D95A7437ACE3431650453 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > > >OK, how about: > > > > "extensibleMatch filters can also use matching rules from an > > attribute type's AttributeType description." > > I don't think that's correct. Listing a rule in > an attribute type description doesn't imply that > rule can be used in an extensibleMatch filter. > I disagree. I think it is correct. For example, if you want to use typeless matching you can specify just the matching rule without the attribute type, and every AT that has that matching rule in its AT description will be matched against. David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 01484 532930 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------B55D95A7437ACE3431650453 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------B55D95A7437ACE3431650453-- From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 14 11:40: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 LAA26514 for ; Fri, 14 Feb 2003 11:40: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 h1EFkBOw044401; Fri, 14 Feb 2003 16:02:06 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 h1EFcJCM043855; Fri, 14 Feb 2003 15:38:19 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 15:38:19 +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 h1EFcGOK043845 for ; Fri, 14 Feb 2003 15:38:17 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.6) with ESMTP id h1EFc88O083152; Fri, 14 Feb 2003 15:38:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030214063448.0269e398@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 07:36:36 -0800 To: David Chadwick From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses Cc: Hallvard B Furuseth , ietf-ldapbis@OpenLDAP.org In-Reply-To: <3E4CE7FF.76C303E9@salford.ac.uk> References: <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@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 04:58 AM 2/14/2003, David Chadwick wrote: >I disagree. I think it is correct. For example, if you want to use >typeless matching you can specify just the matching rule without the >attribute type, and every AT that has that matching rule in its AT >description will be matched against. In an extensibleMatch search filter, if the type is absent and the rule present, then the value is matched against all attribute types which support that rule. The set of attribute types may include attribute types which have no defined EQUALITY rule, attribute types which have a different EQUALITY rule, or attribute types which have the same EQUALITY rule. Suitability of rule for use against values of an attribute type is NOT indicated in the specification of the attribute type description for the type, but by specification of a matching rule description for the rule. This, I believe, is quite clear by the language used in RFC 2251 and 2252. In particular, RFC 2252, 4.2, Attribute Types: Note that the AttributeTypeDescription does not list the matching rules which can can be used with that attribute type in an extensibleMatch search filter. This is done using the matchingRuleUse attribute described in section 4.5. RFC 2252, 4.5, Matching Rules: Values of the matchingRuleUse list the attributes which are suitable for use with an extensible matching rule. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 14 13:50: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 NAA00729 for ; Fri, 14 Feb 2003 13:50: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 h1EIkGOY057644; Fri, 14 Feb 2003 18:52: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 h1EITF8Q057134; Fri, 14 Feb 2003 18:29:15 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 14 Feb 2003 18:29: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 h1EITCOK057124 for ; Fri, 14 Feb 2003 18:29:12 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.6) with ESMTP id h1EIT38O084604 for ; Fri, 14 Feb 2003 18:29:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030214101509.024d9a28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 10:27:32 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: Models: Matching Rule Uses In-Reply-To: <5.2.0.9.0.20030214063448.0269e398@127.0.0.1> References: <3E4CE7FF.76C303E9@salford.ac.uk> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030210134510.0276be18@127.0.0.1> <5.2.0.9.0.20030212145749.02507b78@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:36 AM 2/14/2003, Kurt D. Zeilenga wrote: >At 04:58 AM 2/14/2003, David Chadwick wrote: >>I disagree. I think it is correct. For example, if you want to use >>typeless matching you can specify just the matching rule without the >>attribute type, and every AT that has that matching rule in its AT >>description will be matched against. > >In an extensibleMatch search filter, if the type is absent and >the rule present, then the value is matched against all attribute >types which support that rule. The set of attribute types may >include attribute types which have no defined EQUALITY rule, >attribute types which have a different EQUALITY rule, or attribute >types which have the same EQUALITY rule. This is more correct (in my opinion): The set of attribute types may include attribute types which have the same or different EQUALITY rule. The set cannot contain any attribute type which has no EQUALITY rule as no comparisons whatsoever are possible without an EQUALITY rule (per X.501(93), 12.4.5). The following, however, is still correct (in my opinion). >Suitability of rule for use against values of an attribute type >is NOT indicated in the specification of the attribute type >description for the type, but by specification of a matching rule >description for the rule. This, I believe, is quite clear by >the language used in RFC 2251 and 2252. In particular, > >RFC 2252, 4.2, Attribute Types: > Note that the AttributeTypeDescription does not list the matching > rules which can can be used with that attribute type in an > extensibleMatch search filter. This is done using the > matchingRuleUse attribute described in section 4.5. > >RFC 2252, 4.5, Matching Rules: > Values of the matchingRuleUse list the attributes which are > suitable for use with an extensible matching rule. From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 17 00:13: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 AAA04967 for ; Mon, 17 Feb 2003 00:13: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 h1H56GOO013388; Mon, 17 Feb 2003 05:16: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 h1H4x5Cv012901; Mon, 17 Feb 2003 04:59:05 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Mon, 17 Feb 2003 04:59:05 +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 h1H4x1OK012857 for ; Mon, 17 Feb 2003 04:59:01 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Sun, 16 Feb 2003 21:48:37 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 14 Feb 2003 16:29:17 -0700 From: "Jim Sermersheim" To: Subject: Re: Add values without equality matching rule 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 believe the new wording in Section 2.3 of Models sufficiently explains the requirement, and that the sentence from Section 4.6 of Protocols (below) can be removed. Jim >>> "Kurt D. Zeilenga" 1/17/03 12:56:16 PM >>> 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 Tue Feb 18 18:23: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 SAA11290 for ; Tue, 18 Feb 2003 18:23: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 h1INGKP6076514; Tue, 18 Feb 2003 23:25: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 h1INCIbM076275; Tue, 18 Feb 2003 23:12:18 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 18 Feb 2003 23:12:18 +0000 Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by galois.openldap.org (8.12.6/8.12.6) with ESMTP id h1INCDOK076264 for ; Tue, 18 Feb 2003 23:12:14 GMT (envelope-from norbert+lists.ietf-ldapbis@burgundy.dyndns.org) Received: from fwd11.sul.t-online.de by mailout05.sul.t-online.com with smtp id 18lGuK-00038R-06; Wed, 19 Feb 2003 00:12:12 +0100 Received: from burgundy.dyndns.org (520009743106-0001@[217.226.29.42]) by fmrl11.sul.t-online.com with esmtp id 18lGuG-11CDseC; Wed, 19 Feb 2003 00:12:08 +0100 Received: from localhost (localhost [127.0.0.1]) by burgundy.dyndns.org (Postfix) with ESMTP id 01B396F1F for ; Wed, 19 Feb 2003 00:12:08 +0100 (CET) Received: from [10.10.9.3] (trex.local [10.10.9.3]) by burgundy.dyndns.org (Postfix) with ESMTP id 0E34A6F04 for ; Wed, 19 Feb 2003 00:12:04 +0100 (CET) Date: Wed, 19 Feb 2003 00:12:03 +0100 From: Norbert Klasen To: ietf-ldapbis@OpenLDAP.org Subject: matching rules for Facsimile Telephone Number Message-ID: <27190628.1045613523@[10.10.9.3]> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Sender: 520009743106-0001@t-dialin.net 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, the ITU has issued a Technical Corrigendum to X.520 which adds the missing equality and substrings matching rules to the Facsimile Telephone Number attribute: http://www.itu.int/dms_pub/itu-t/rec/x/T-REC-X.520-200204-I!Cor1!PDF-E.pdf The revised RFC2256 (draft-ietf-ldapbis-user-shema) should be changed accordingly. BTW: Is the commonly used short name "fax" defined anywhere? Norbert From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 23 12:08:13 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 MAA09907 for ; Sun, 23 Feb 2003 12:08: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 h1NGaVOu012624; Sun, 23 Feb 2003 17:10: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 h1NGSrn6012430; Sun, 23 Feb 2003 16:28:53 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Sun, 23 Feb 2003 16:28: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 h1NGSoOK012420 for ; Sun, 23 Feb 2003 16:28:50 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.6) with ESMTP id h1NGSZ8q070688; Sun, 23 Feb 2003 16:28:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030223072157.02cbc9f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 23 Feb 2003 08:26:57 -0800 To: Norbert Klasen From: "Kurt D. Zeilenga" Subject: Re: matching rules for Facsimile Telephone Number Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <27190628.1045613523@[10.10.9.3]> 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 note that the corrigendum changes the 4th edition of X.520 and hence is not directly applicable to LDAP. We've clarified X.500 in "MUST act in accordance with X.500" to refer to the 2nd edition of X.500. The corrigendum not only alters the 'facsimile' attribute type description, but introduces two new matching rules. It is my opinion (as co-chair) that the LDAPbis cannot take on work in this area as our charter states that non-"core" schema is beyond our scope. Kurt At 03:12 PM 2/18/2003, Norbert Klasen wrote: >Hi, >the ITU has issued a Technical Corrigendum to X.520 which adds the missing >equality and substrings matching rules to the Facsimile Telephone Number >attribute: >http://www.itu.int/dms_pub/itu-t/rec/x/T-REC-X.520-200204-I!Cor1!PDF-E.pdf > >The revised RFC2256 (draft-ietf-ldapbis-user-shema) should be changed accordingly. > >BTW: Is the commonly used short name "fax" defined anywhere? > >Norbert From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 24 23:54: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 XAA06198 for ; Mon, 24 Feb 2003 23:54: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 h1P4uYOO039077; Tue, 25 Feb 2003 04:57: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 h1P4lLh4038980; Tue, 25 Feb 2003 04:47:21 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Tue, 25 Feb 2003 04:47:21 +0000 Received: from nexus.adacel.com ([210.11.130.1]) by galois.openldap.org (8.12.6/8.12.6) with SMTP id h1P4lFOK038942 for ; Tue, 25 Feb 2003 04:47:17 GMT (envelope-from steven.legg@adacel.com.au) Received: (qmail 25538 invoked from network); 25 Feb 2003 04:46:54 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 25 Feb 2003 04:46:54 -0000 Reply-To: From: "Steven Legg" To: "'Hallvard B Furuseth'" , Subject: RE: Insignificant space in matching rules Date: Tue, 25 Feb 2003 15:45:13 +1100 Message-ID: <005401c2dc88$b0189820$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: 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: > Sent: Sunday, 19 January 2003 7:47 > [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. An empty string is invalid in the protocol, but it is not invalid as an input to a server's internal implementation of the matching rule functionality. Nor does "ignore" mean that a server must physically transform the input strings before applying the matching rule function. The current description is fine, and carries the implication that any assertion or attribute value containing only one or more spaces is equivalent to an empty string for comparison purposes. Two empty strings obviously match. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 26 04:01: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 EAA28659 for ; Wed, 26 Feb 2003 04: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 h1Q8ssh7011576; Wed, 26 Feb 2003 09:03: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 h1Q8jirH010652; Wed, 26 Feb 2003 08:45:44 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Wed, 26 Feb 2003 08:45:44 +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 h1Q8jeh3010538 for ; Wed, 26 Feb 2003 08:45:40 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 26 Feb 2003 01:35:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Wed, 26 Feb 2003 01:44:39 -0700 From: "Jim Sermersheim" To: , "Roger Harrison" , Subject: Re: Syntaxes draft on directory updates 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 would think Section 3 of AuthMeth Jim >>> Hallvard B Furuseth 11/26/02 3:39:39 AM >>> draft-ietf-ldapbis-syntaxes-03.txt says: > 5.3 Securing the Directory > > In order to protect the directory and its contents, strong > authentication MUST have been used to identify the Client when an > update operation is requested. That seems a strange place to put this information. I think it belongs in the Protocol draft. -- Hallvard From owner-ietf-ldapbis@openldap.org Thu Feb 27 13:47: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 NAA16445 for ; Thu, 27 Feb 2003 13:47: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 h1RIEwhp013502; Thu, 27 Feb 2003 18:50: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 h1RIDOOp013246; Thu, 27 Feb 2003 18:13:24 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 27 Feb 2003 18:13:24 +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 h1RIDGh7013158 for ; Thu, 27 Feb 2003 18:13:17 GMT (envelope-from Kurt@OpenLDAP.org) 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 h1RHiWWG057470 for ; Thu, 27 Feb 2003 17:44:32 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.6) with ESMTP id h1RHiO8q020903 for ; Thu, 27 Feb 2003 17:44:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030227093121.01a093b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Feb 2003 09:42:43 -0800 To: ietf-ldapbis@openldap.org From: "Kurt D. Zeilenga" Subject: internationalization of textual passwords 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: While the simple bind password and userPassword are OCTET STRINGs and to be compared using octetStringMatch (and I continue to think this should not be changed, see past discussions), I (as an individual) think it would be appropriate to RECOMMEND that clients which provide textual passwords "prepare", using SASLprep, the string before transmission to the server to ensure that like passwords will match. Use of SASLprep here, aside from ensuring consistency between all LDAP clients desiring to use textual passwords, would allow the textual strings to be used in various SASL mechanisms which use SASLprep. Comments? Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 27 14:21: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 OAA17770 for ; Thu, 27 Feb 2003 14:21: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 h1RJP0h3021269; Thu, 27 Feb 2003 19:25: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 h1RJ64f4020530; Thu, 27 Feb 2003 19:06:04 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Thu, 27 Feb 2003 19:06:04 +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 h1RJ5sh3020519 for ; Thu, 27 Feb 2003 19:05:54 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.6) with ESMTP id h1RJ5k8q022032 for ; Thu, 27 Feb 2003 19:05:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030227110313.03bbc9a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Feb 2003 11:04:05 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: internationalization of textual passwords In-Reply-To: <5.2.0.9.0.20030227093121.01a093b8@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: BTW, SASLprep is detailed in: http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-00.txt Kurt At 09:42 AM 2/27/2003, Kurt D. Zeilenga wrote: >While the simple bind password and userPassword are OCTET STRINGs >and to be compared using octetStringMatch (and I continue to think >this should not be changed, see past discussions), I (as an >individual) think it would be appropriate to RECOMMEND that clients >which provide textual passwords "prepare", using SASLprep, the >string before transmission to the server to ensure that like >passwords will match. Use of SASLprep here, aside from ensuring >consistency between all LDAP clients desiring to use textual >passwords, would allow the textual strings to be used in various >SASL mechanisms which use SASLprep. > >Comments? > >Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 28 00:49: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 AAA04356 for ; Fri, 28 Feb 2003 00:49: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 h1S5iwh9083773; Fri, 28 Feb 2003 05:52: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 h1S5cq1Y082984; Fri, 28 Feb 2003 05:38:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 28 Feb 2003 05:38:52 +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 h1S5cjh3082877; Fri, 28 Feb 2003 05:38:45 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 27 Feb 2003 22:38:24 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 27 Feb 2003 22:38:00 -0700 From: "Jim Sermersheim" To: , Cc: "Alan Clark" , "Dan Fritch" , "David Ward" , "Hal Henderson" , "Tolga Acar" Subject: Re: internationalization of textual passwords 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 haven't read SASLPrep yet, but recommending (and in doing so, raising awareness of the issue) a normalized string form sounds very good to me. Jim >>> "Kurt D. Zeilenga" 2/27/03 11:12:43 PM >>> While the simple bind password and userPassword are OCTET STRINGs and to be compared using octetStringMatch (and I continue to think this should not be changed, see past discussions), I (as an individual) think it would be appropriate to RECOMMEND that clients which provide textual passwords "prepare", using SASLprep, the string before transmission to the server to ensure that like passwords will match. Use of SASLprep here, aside from ensuring consistency between all LDAP clients desiring to use textual passwords, would allow the textual strings to be used in various SASL mechanisms which use SASLprep. Comments? Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 28 13:50: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 NAA08739 for ; Fri, 28 Feb 2003 13:50: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 h1SIixh7047487; Fri, 28 Feb 2003 18:53: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 h1SIeewL047036; Fri, 28 Feb 2003 18:40:40 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 28 Feb 2003 18:40:40 +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 h1SIeXh3046976 for ; Fri, 28 Feb 2003 18:40:33 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Feb 2003 11:40:12 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 28 Feb 2003 11:37:13 -0700 From: "Jim Sermersheim" To: , Subject: Re: TLS closure alert and auth/authz ID 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 Hallvard, I'm not sure I like this. Basically I think you're trying to simplify the wording by saying that the server should perform an implicit anonymous bind (this also solves the "what to do with outstanding operations" issue you had). But this feels too much like we're dictating how a server is to be written in order to instruct how it is to behave. I think it's OK to tell a server how to behave, and let implementors solve the implementation details however they want. Jim >>> Hallvard B Furuseth 11/22/02 3:51:35 AM >>> [authmeth] says: > 5.2.2. TLS Connection Closure Effects > > Closure of the TLS connection MUST cause the LDAP association to > move to an anonymous authentication and authorization state > regardless of the state established over TLS and regardless of the > authentication and authorization state prior to TLS connection > establishment. I think this information belongs in [Protocol], except the part about authz ID. If I have understood it correctly, this should cover it: [Protocol] 4.13.3.1: Closure of the TLS connection causes the server to perform an implicit bind operation with version preserved, an empty name, and simple authentication with empty password. [Authmeth]: A simple bind with a null name cause the LDAP association to move to an anonymous authentication and authorization state. I can't find the latter stated explicitly in [Authmeth] - not the part of about authz id, anyway. Does the part about simple authentication break anything if more complex authentication had been in effect? -- Hallvard From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 28 14:20:19 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 OAA09492 for ; Fri, 28 Feb 2003 14:20: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 h1SJExhD050609; Fri, 28 Feb 2003 19:23:30 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 h1SJ73Sm049656; Fri, 28 Feb 2003 19:07:03 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 28 Feb 2003 19:07:03 +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 h1SJ6xh3049616 for ; Fri, 28 Feb 2003 19:06:59 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Feb 2003 12:06:39 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 28 Feb 2003 12:05:34 -0700 From: "Jim Sermersheim" To: , Subject: Re: Add and Modify DN Operations in [Protocol]-12 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 K, I changed add to "The parent of the object and alias entries to be added MUST exist.". Because there are a number of other DSE types that could be added without a parent. For modDN, here's what X.511 says: "The newSuperior argument, if present, specifies that the entry is to be moved to a new superior in the DIT. The entry becomes an immediate subordinate of the entry with the indicated Distinguished Name, which must be an already existing object entry. The new superior shall not be the entry itself or any of its subordinates, or an alias, or such that the moved entry violates any DIT structure rules. It is possible that entries subordinate to the moved entry may violate the active subschema, in which case it is the responsibility of the Subschema Administrative Authority to make subsequent adjustments to these entries to make them consistent with the subschema, as described in ITU-T Rec. X.501 | ISO/IEC 9594-2, clause 13." For now, I'll add the bit about the parent already existing. But... I guess my point is. There's a ton of stuff like this in X.511. Jim >>> Hallvard B Furuseth 1/10/03 12:10:58 AM >>> > 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 Fri Feb 28 14:24: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 OAA09635 for ; Fri, 28 Feb 2003 14:24: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 h1SJOxh7051386; Fri, 28 Feb 2003 19:28: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 h1SJKqiQ051143; Fri, 28 Feb 2003 19:20:52 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 28 Feb 2003 19:20:52 +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 h1SJKkh3051126 for ; Fri, 28 Feb 2003 19:20:46 GMT (envelope-from jimse@novell.com) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Feb 2003 12:20:26 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 28 Feb 2003 12:19:39 -0700 From: "Jim Sermersheim" To: , , Subject: RE: How are approxMatch matching rules declared? 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 now it says: The matching rule for approxMatch filter items is implementation-defined. If approximate matching is not supported by the server, the filter item should be treated as an equalityMatch. Does something need to be changed? Jim >>> "Steven Legg" 2/3/03 10:17:29 AM >>> Hallvard, Hallvard B Furuseth wrote: > [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. That's because there are practically no matching rules defined which describe approximate matching semantics. For the most part, if such a field were defined there would be nothing with which to populate it. The semantics of an approximate match filter item have always been left to the discretion of the server implementations. > 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? In principle, every attribute type with an equality matching rule supports approximate matching though in practice it might not differ from the equality match. > Should [Models] say something about this? More likely the protocol draft since that is where the search operation is described. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 28 14:52: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 OAA10658 for ; Fri, 28 Feb 2003 14:52: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 h1SJsxh7053132; Fri, 28 Feb 2003 19:55: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 h1SJjSlg052885; Fri, 28 Feb 2003 19:45:28 GMT (envelope-from owner-ietf-ldapbis@OpenLDAP.org) Received: by OpenLDAP.org (bulk_mailer v1.13); Fri, 28 Feb 2003 19:45:28 +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 h1SJjMh3052875 for ; Fri, 28 Feb 2003 19:45:22 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.6) with ESMTP id h1SJjC8q034212; Fri, 28 Feb 2003 19:45:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030228112614.02a14d28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 11:43:29 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Add and Modify DN Operations in [Protocol]-12 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:05 AM 2/28/2003, Jim Sermersheim wrote: >K, I changed add to "The parent of the object and alias entries to be >added MUST exist.". Because there are a number of other DSE types that >could be added without a parent. I don't think any major clarification is really needed (but maybe just a few tweaks). >>>> Hallvard B Furuseth 1/10/03 12:10:58 AM >>>> >> 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. No. Even if the entry is the initial vertex of a naming context, its parent (except where the naming context prefix has only one RDN) should exist in the superior naming context. However, in this case where the server doesn't shadow the superior naming context, the server processing the Add request should not be required to ensure the parent actually does exist. Likewise for Modify DN. Kurt