Re: Questions on extensible matching rules

[Julio Sánchez Fernández <j_sanchez@stl.es>]

"Kurt D. Zeilenga" wrote:
> 
> >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?

To be precise, the syntax of the attribute type corresponding
to the attribute description in the filter.

> In testing an assertion, the stored value is always normalized
> per its syntax (by value_normalize).

Then, we don't need it to normalize the asserted value, do we?
As a matter of fact, it seems none of the existing normalization
functions use that argument.  Can you provide an example of
where might it be needed?

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

Are we talking about value_normalize or the normalizer
method itself?

The current situation is that value_normalize calls mr->smr_normalize
if defined or mr->smr_syntax->ssyn_normalize.  This it correct,
since it is either the one in the matching rule or the one for
the syntax of the asserted value.

The problem now is that the normalization methods get called
with ad->ad_type->sat_syntax as a first parameter, i.e. the
syntax of the stored value.  And we might not have that in some
extensible matches, e.g. '(:2.5.13.4:=*John*)'.

So, we can:

	- Kill that argument
	- Redefine it to mean syntax in the asserted value
	- Declare that normalizers must accept that it be NULL
	- Delay asserted value normalization until we know the
	  attribute type (possibly precomputing the different
	  normalizations so that it need not be done n times
	  per inspected directory entry)
	- Forget about doing extensible matches without
	  attribute descriptions

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

I don't know, I think the asserted value should be normalized
against its syntax, that need not be the same as that in the 
asserted attribute description. It is the case of
objectIdentifierFirstComponentMatch and the like.

On the other hand, the matching rule needs to know at some time
the syntax of the stored value and that knowledge is not 
explicit in the schema, but it is obvious that matching rules
are only compatible with some syntaxes and not others.  For
instance, the proverbial objectIdentifierFirstComponentMatch
is only compatible with syntaxes that are ASN.1 things that
start with a non-optional OID (or the textual representations
of those things, such as MatchingRuleDescription and the like).
But it is meaningless for a DirectoryString, for instance.

And that is not explicit anywhere. MatchingRuleUse would be
the place, actually, but it is supposed to be just for
extensible matches and is not defined in terms of syntaxes,
but of attribute types instead.  A big PITA, if you ask me.

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

Actually, it is there, it is smr_syntax.  The matching rule
defines the syntax of the asserted value.

Julio