Subject: substring filters using DN attributes ?

From: sanjay jain <[email-masked]>
Date: Fri, 21 Jul 2000 16:45:32 -0700

It looks like from standard LDAP schema that

substring matching is not allowed for DN syntax

attributes.  E.g. for 'member' attribute.

Does it mean from http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.txt

section 5.2.2.1.3 that if an LDAP server gets a filter

like: member=*dc=org1,dc=com

it should return 'inappropriateMatching' error code ?

thanks

sanjay

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 Jul 2000 17:17:56 -0700

At 04:45 PM 7/21/00 -0700, sanjay jain wrote:
>Does it mean from <http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.txt>http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.txt 

No.

The filter (member=*dc=org1,dc=com) is Undefined.  The operation
may complete successful with no entries being returned.

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 23 Jul 2000 09:26:52 +0100

Date forwarded: 	Fri, 21 Jul 2000 17:18:07 -0700 (PDT)
Date sent:      	Fri, 21 Jul 2000 17:17:56 -0700
To:             	sanjay jain <[email-masked]>
From:           	"Kurt D. Zeilenga" <[email-masked]>
Subject:        	Re: substring filters using DN attributes ?
Copies to:      	ldapext <[email-masked]>
Forwarded by:   	[email-masked]

I think we have an excellent case here for the introduction of a new 
matching rule that will indeed allow matches of the type required on 
DNs.

David

> >Does it mean from
> ><http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.tx
> >t>http://www.ietf.org/internet-drafts/draft-just-ldapv3-rescodes-02.t
> >xt section 5.2.2.1.3 that if an LDAP server gets a filter like:
> >member=*dc=org1,dc=com it should return 'inappropriateMatching' error
> >code ? 
> 
> No.
> 

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: Mark Wahl <[email-masked]>
Date: Mon, 24 Jul 2000 13:37:42 -0500

The default is that the matching rule will not match any values since
it doesn't know how to compare.  (But the client shouldn't have sent that
query in the first place without discovering the schema :-) )

There has been some interest from a number of implementors and users to have
matching rules for partial DNs but no I-Ds have yet been published in this 
ares.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 24 Jul 2000 11:55:14 -0700

>matching rules for partial DNs but no I-Ds have yet been published in this 

I've meaning to publish a regexMatch rule I-D which would allow
matching of an asserted regular expression against the string
representation of attribute values.  Of course, to be useful with
DNs, we'd have to have to define a canonical string representation
of DNs.  Given such, you would be able to do DN matching like:

        (member:regexMatch:=.*,dc=example,dc=com$)

Such a matching rule, I believe, would be generally useful in
a number of applications.  Of course, user applications may
not want to expose regular expressions to average Joe.

If others concur that this would be generally useful, I'll put
up a straw man proposal after IETF#48.

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Tue, 25 Jul 2000 09:35:58 -0700

> up a straw man proposal after IETF#48.

It would be interesting to see examples of the kinds of LDAP application
problems that would be more easily addressed if such a matching rule was
available.  If all we really need is a way to anchor the start and end
of strings (i.e., ^ and $ from regex), I'd rather see a more narrow
proposal.  Why?  Because general regular expression matching will be
quite difficult to support using indexes, etc.

-- 
Mark Smith
Directory Product Development / Netscape Communications
My words are my own, not my employer's.            Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 25 Jul 2000 13:41:17 -0700

At 09:35 AM 7/25/00 -0700, Mark C Smith wrote:
>available.

I agree.  In fact, I wouldn't attempt to write such an I-D
without decent examples.  In general, such a rule would be useful
to applications which required very specific, complex matching
which cannot easily be decomposed into a substrings assertion.
I'll try to come up with some examples, hopefully ones which
are not too contrived.

>If all we really need is a way to anchor the start and end

I concur that general regular expressions are quite difficult to
to support using indexing.  I also concur that applications wanting
to make an assertion should use an appropriate matching rule.  I
fully agree that applications wanting to simply assert start/end
text should use a substrings matching rules.

Kurt

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Wed, 26 Jul 2000 12:29:29 +0200

Kurt,

Is there a standard definition  of what a regular expression actually is ?

I ask this because if you work on Solaris for example, there are n different
libraries and functions for doing regular expression matching so the meaning
of "regular expression" is not so obvious.

Rob.

---

From: Chris Harding <[email-masked]>
Date: Wed, 26 Jul 2000 12:37:09 +0100

>Is there a standard definition  of what a regular expression actually is ?
There certainly is.

It is part of the standard definition of the UNIX(TM) operating system
which is available (foc) from The Open Group, see
http://www.opengroup.org/publications/catalog/t912.htm#medium2

The definition of regular expressions is at
http://www.opengroup.org/onlinepubs/007908799/xbd/re.html

>> text should use a substrings matching rules.

Regards,

Chris
+++++

========================================================================
           Chris Harding
  T H E    Directory Program Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:[email-masked]  Phone:  +44 118 950 8311 x2262
           WWW: http://www.opengroup.org   Mobile: +44 771 8588820  
========================================================================

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 26 Jul 2000 13:17:45 -0700

Example A

User wants to return all entries which contain
uid values shorter than 5 characters.

  (uid:regexMatch:=^.{,5}$)

Example B

User wants to find all entries which contain name
attributes with start or end with trailing white
space or contain duplicate spaces.
  (name:regexMatch:=\28^[:space:]|[:space:]{2,}|[:space:]$\29)

Note required escaping.

Example C

User wants to match all names which contain
a common immediately after the first word (such as
"Smith, John" but not "John Smith, Jr.".   That is,
match the the regex "^ *[^ ]*," or the filter:
is (name:regexMatch:=^ \2a[^ ]\2a,).

Example D

User wants to match all values which start with A or B
and end with C or D.  That is: should match the regex
	^(A|B).*(C|D)$

This should match as follows:
	#	value		match
	1	A X		false
	2	A X C		true
	3	A X D		true
	4	B X		false
	5	B X C		true
	6	B X D		true
	7	X C		false
	8	X D		false

Now, lets say in within scope entries with attribute 'attr'
each of which contains a subset of the following values
and we want to return just those which contain a matching
value, that is: (attr:regexMatch:=^\28A|B\29.\2a\28C|D\29$).

This rather simple regex cannot be decomposed into a single
substrings assertion, but could be decomposed into a complex
filter:
	(|(attr=A*C)(attr=A*D)(attr=B*C)(attr=B*D))

Remarks:

I do believe that most assertions made by Joe User can be
(and should be) expressed without the need for extensible
matching and, in particular, regexMatch.  However, regular
expressions offer immense amount of power which can be applied
to any string value and, as demonstrated above, can be used
to make assertions which are not supported by existing
rules.  Of course, as Mark pointed out, such power comes at
a price.

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Thu, 27 Jul 2000 08:56:57 +0200

Kurt,

For regex on  a dn, here's an example to say "match any value of a
particular RDN attribute".
eg. match each dn like "cn=admin,ou=X,o=sun.com" where the X will match
any, though just, the value of ou (which in particular may contain an
escaped comma).

A Unix extended regular expression for this matching is
"^uid=admin,ou=\([^,]*\\,\)*[^,]*,o=sun.com$"

Rob.