[Date Prev][Date Next]
Re: Questions on extensible matching rules
At 07:49 PM 10/23/00 +0200, Julio Sánchez Fernández wrote:
>We usually follow the procedure that on an incoming search
>request we normalize the asserted value using the normalization
>function of the matching rule, if any is defined. Otherwise,
>we try the normalization function of the syntax of the asserted
>value (known from the matching rule).
Yes. A matching rule defines the syntax of the asserted value.
This syntax has a normalization function. The syntax normalizer
is designed to support most matchings needs, however, some rules
many need to apply a different normalization function to the
asserted value, hence the existence of a matching rule specific
>This happens in value_normalize() in servers/slapd/value.c.
>However, we give now those normalization functions the syntax
>of the real attribute as an argument.
real attribute? You mean the held or stored attribute?
In testing an assertion, the stored value is always normalized
per its syntax (by value_normalize).
>Is there any reason for that? I want to lose it, because a
>search with an extensible matching rule that did not specify
>an attribute description, well, does not have an attribute
Regardless of whether or not an attribute type is specified,
the asserted value needs to be normalized (possibly in a
matching rule specific manner) per the assertion syntax.
Hence, the syntax argument to the normalizer is a must.
What I suggest is that the switch cases set a local variable
'syntax' which is then passed into normalizers. For
non-SLAP_MR_EXT, this syntax would be that of the asserted
attribute description (ad->ad_type->sat_syntax). For
SLAP_MR_EXT, it's whatever is appropriate.
Alternatively, we could modify the matching rule structure
to contain a reference to assertion syntax. This might
actually be cleaner.
>Also, I have found this interesting section in RFC 2252:
>8. Matching Rules
> Servers which implement the extensibleMatch filter SHOULD allow all
> the matching rules listed in this section to be used in the
> extensibleMatch. In general these servers SHOULD allow matching
> rules to be used with all attribute types known to the server, when
> the assertion syntax of the matching rule is the same as the value
> syntax of the attribute.
Yes. That is, if the held value is syntax X, one should be able to
use any matching rule in which the assertion syntax X.
>That suggests we be liberal in this. There is even special syntax
>to deal with substring matches.
Note that Substrings extended matching is not well specified.
There been some discussion on LDAPext regarding issues with
this. For now, I suggest you skip this.
>How to deal with an extensible
>match when an ordering matching rule is chosen, however, remains a
One would need to define a syntax similar to substrings assertion
syntax to specify the ordering to use. I suggest you skip this