Hi,
first of all, please excuse me if I've hit the wrong openldap mailinglist.
My question below is related to section 4.1 of RFC4517 which says:
Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion syntax of the matching rule is the same as the value syntax of the attribute.
Could someone please explain to me why openldap currently doesn't support for example 'caseIgnoreOrderingMatch' (which is listed in section 4.2 of RFC4517) in extensible match filters? Of course I've seen the two SHOULDs above - I just don't understand the openldap related technical/design decision regarding the missing support and would be very happy if someone could please explain this to me.
Another more common question but also related to my previous mail (below): could someone please also tell me the RFC(s) in which the evaluation of ordering matching rules (especially when used in extensible match filters) is specified?
Thanks again!
Betreff: Support for ordering matching rules in extensible match filters? Datum: Thu, 22 Apr 2010 11:18:35 +0200 Von: Daniel deepee@gmx.net An: openldap-technical@openldap.org
Hi,
why doesn't slapd support ordering matching rules in extensible match filters?
Does the small code enhancement for slapd's generalizedTimeOrderingMatch() would make sense into the direction to support ordering matching in extensible filters (in this particular case)?
Thanks a lot!
static int generalizedTimeOrderingMatch( int *matchp, slap_mask_t flags, Syntax *syntax, MatchingRule *mr, struct berval *value, void *assertedValue ) { struct berval *asserted = (struct berval *) assertedValue; ber_len_t v_len = value->bv_len; ber_len_t av_len = asserted->bv_len;
/* ignore trailing 'Z' when comparing */ int match = memcmp( value->bv_val, asserted->bv_val, (v_len < av_len ? v_len : av_len) - 1 );
Debug( LDAP_DEBUG_TRACE, "gTOM1: %s %s %d\n", value->bv_val, asserted->bv_val, match);
if ( flags & SLAP_MR_EXT ) { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => SLAP_MR_EXT (%ld) [%d %d]\n", flags, 0, 0); if ( match == -1 ) match = 0; else if ( match == 0 ) match = 1; } else { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => ? (%ld) [%d %d]\n", flags, 0, 0); if ( match == 0 ) match = v_len - av_len; }
Debug( LDAP_DEBUG_TRACE, "gTOM2: %s %s %d\n", value->bv_val, asserted->bv_val, match);
*matchp = match; return LDAP_SUCCESS; }
--On Saturday, April 24, 2010 8:15 PM +0200 deepee@gmx.net wrote:
Hi,
first of all, please excuse me if I've hit the wrong openldap mailinglist.
My question below is related to section 4.1 of RFC4517 which says:
Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion syntax of the matching rule is the same as the value syntax of the attribute.
Could someone please explain to me why openldap currently doesn't support for example 'caseIgnoreOrderingMatch' (which is listed in section 4.2 of RFC4517) in extensible match filters? Of course I've seen the two SHOULDs above - I just don't understand the openldap related technical/design decision regarding the missing support and would be very happy if someone could please explain this to me.
Probably no one has implemented them previously. You could file an ITS with your contribution for consideration at http://www.openldap.org/its. Make sure you read the contribution guidelines:
http://www.openldap.org/devel/contributing.html
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Saturday, April 24, 2010 8:15 PM +0200 deepee@gmx.net wrote:
Could someone please explain to me why openldap currently doesn't support for example 'caseIgnoreOrderingMatch' (which is listed in section 4.2 of RFC4517) in extensible match filters? Of course I've seen the two SHOULDs above - I just don't understand the openldap related technical/design decision regarding the missing support and would be very happy if someone could please explain this to me.
Probably no one has implemented them previously. You could file an ITS with your contribution for consideration at http://www.openldap.org/its. Make sure you read the contribution guidelines:
Ok, I've filed an ITS. Its ID is 6532.
openldap-technical@openldap.org