[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
normalizer.

>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
>description.

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
>mistery. 

One would need to define a syntax similar to substrings assertion
syntax to specify the ordering to use.  I suggest you skip this
as well.

Kurt