Am Wed, 14 Nov 2012 19:51:13 +0000 schrieb Chris Card ctcard@hotmail.com:

Thanks, but I don't see anything about these matching rules in Rfc4517 section 4.

Substring assertion is discussed in section 3

...

...

Hi all,

I see that openldap supports a number of matching rules for DNs, e.g. dnOneLevelMatch, dnSubtreeMatch, dnSubordinateMatch and dnSuperiorMatch.

Please can someone point me to documentation about these matching rules? (Google doesn't seem to bring up much useful).

RFC 4517, section 4.

-Dieter

-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

...

...

...

...

I see that openldap supports a number of matching rules for DNs, e.g. dnOneLevelMatch, dnSubtreeMatch, dnSubordinateMatch and dnSuperiorMatch.

Please can someone point me to documentation about these matching rules? (Google doesn't seem to bring up much useful).

RFC 4517, section 4.

Thanks, but I don't see anything about these matching rules in Rfc4517 section 4.

Substring assertion is discussed in section 3

I'm not trying to awkward, but I don't see how that relates to my question.

I understand how to use the matching rules syntactically, but I have not found documentation anywhere that describes how these matching rules work.

I can try out examples and/or read the openldap source code to try and deduce their behaviour, but I'd prefer to see documentation.

I have done some more investigation and experiments, and this is what I've found:

1. there is no documentation that I can find online defining the behaviour of the matching rules dnOneLevelMatch, dnSubtreeMatch, dnSubordinateMatch and dnSuperiorMatch. 2. these matching rules are mentioned here: http://www.openldap.org/faq/data/cache/1101.html, and all have OIDs under 1.3.6.1.4.1.4203.666. 3. this page http://www.openldap.org/faq/data/cache/200.html, which describes OID 1.3.6.1.4.1.4203.666 says "OpenLDAP Experimental OIDs are assigned to protocol items with an evolving specification (e.g., a work in progress) under development by the OpenLDAP Project. The specification can be revised without assigning a new OID. No released software should use an OID under this arc."  4. an example using dnSubtreeMatch is given in the slapcat(8) man page, which seems to imply that these matching rules are no longer experimental. 5. from experiment I think I understand the behaviour of these matching rules, but that is not ideal:     (a) A filter like (entrydn:dnOneLevelMatch:=<targetdn>) restricts the result to entries 1 level subordinate to targetdn.     (b) (entrydn:dnSubtreeMatch:=<targetdn>) restricts the result to the subtree including and under targetdn     (c) (entrydn:dnSubordinateMatch:=<targetdn>) restricts the result to the entries subordinate to targetdn (i.e. the same as dnSubtreeMatch, but excluding the targetdn)     (d) (entrydn:dnSuperiorMatch:=<targetdn>) restricts the result to the entries superior to targetdn

Chris

Chris Card wrote:

Hi,

...

...

...

...

I see that openldap supports a number of matching rules for DNs, e.g. dnOneLevelMatch, dnSubtreeMatch, dnSubordinateMatch and dnSuperiorMatch.

Please can someone point me to documentation about these matching rules? (Google doesn't seem to bring up much useful).

RFC 4517, section 4.

Thanks, but I don't see anything about these matching rules in Rfc4517 section 4.

Substring assertion is discussed in section 3

I'm not trying to awkward, but I don't see how that relates to my question.

I understand how to use the matching rules syntactically, but I have not found documentation anywhere that describes how these matching rules work.

I can try out examples and/or read the openldap source code to try and deduce their behaviour, but I'd prefer to see documentation.

This feature has been present in OpenLDAP since 2004.

https://www.openldap.org/its/private.cgi/Archive.Software%20Enhancements?id=...

Nobody has asked for docs thus far, because everybody recognizes that subtree/onelevel/subordinate are the same as the corresponding LDAP search scopes, and their behavior is already specified.

Chris Card wrote:

...

...

...

...

...

> I see that openldap supports a number of matching rules for DNs, > e.g. dnOneLevelMatch, dnSubtreeMatch, dnSubordinateMatch and > dnSuperiorMatch.

<snip> >> I have not found documentation anywhere that describes how these matching rules work. >> >> I can try out examples and/or read the openldap source code to try and deduce their behaviour, but I'd >> prefer to see documentation. > > This feature has been present in OpenLDAP since 2004. > > https://www.openldap.org/its/private.cgi/Archive.Software%20Enhancements?id=3112;selectid=3112;usearchives=1

...

That link needs a login.

http://www.openldap.org/its/index.cgi/Archive.Software%20Enhancements?id=311...

...

Nobody has asked for docs thus far, because everybody recognizes that subtree/onelevel/subordinate are the same as the corresponding LDAP search scopes, and their behavior is already specified.

Ok, but there's no superior scope. Also, while it's possible to try and deduce behaviour by similarity of names and by experiment, that's not a foolproof method, which is why I asked for a link to documentation. What little documentation I did find indicates that these matching rules are 'experimental' and shouldn't be used in released code (http://www.openldap.org/faq/data/cache/200.html) - is that still the case?

That FAQ says these OIDs shouldn't be used in released code. That's generally true, but obviously we've broken those rules various times. The intent of these rules is that we expect experimental features to either progress, in which case a formal specification is published, using non-experimental OIDs, or the experiments are deemed a failure and withdrawn/deleted. Either way, the experiments actually need to be tested by actual users, which means the corresponding code winds up in public releases.

The reality is that authors of experiments have moved on to other work, leaving these features in limbo, and no one has stepped in to drive them forward to completion (published status).

In this particular case, the features themselves were demonstrably stable years ago.

If you're inclined to only use features that have published documentation, you're welcome to forget everything you ever heard about dnSubtreematch and go about your business. OpenLDAP is a volunteer based open source project - work happens when a volunteer is interested in making it happen. The fact that what you're asking for hasn't been written in the past 8 years indicates to me that no one is interested.