[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Questions on extensible matching rules
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).
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.
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
description.
Any ideas?
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.
Servers MAY implement additional matching rules.
-----
That suggests we be liberal in this. There is even special syntax
to deal with substring matches. How to deal with an extensible
match when an ordering matching rule is chosen, however, remains a
mistery. If anyone has any idea...
Julio