Re: LDAPprep Failure was: Re: LDAPprep: mapping of " " values

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

In response to the empty IA5String discussion I noted my
thought that one could view the size restriction as a
artifact of the particular equality matching rule and
not of the syntax...

Because of the nature of Stringprep, I don't think we
can generally prevent preparation failures.  Even if we
could for LDAPprep, we couldn't for nameprep, saslprep,
and other independently developed profiles.  It is
desirable to allow introduction of LDAP matching rules
which utilize these Stringprep profiles, without having
to jump through too many hops.

One approach here is modify [models] to state that each
individual value of attribute with an equality rule
MUST be equivalent to itself per that rule.

I note that this is behavior of the OpenLDAP server.
Our server prepare values on input and if the preparation
failed, it returns invalidSyntax.

Kurt


>I wrote:
>>In the wider context of component matching (and potentially even within the
>>framework of X.500) there are many ways that the output of LDAPprep could be
>>invalid with respect to the syntax, i.e. ASN.1 type, of the abtract value that
>>supplied the input string. It can change the length of the string such that it
>>is no longer an acceptable length - too short, too long (?) or an
>>explicitly disallowed length. It can introduce space characters where space
>>characters are disallowed. It can create a sequence of characters that
>>no longer satisfies a pattern constraint or value constraint. And so on.
>>And what exactly is the output syntax of LDAPprep in ASN.1 terms ?
>>A UTF8String ? A UniversalString ? That clearly doesn't line up with
>>an input that is a TeletexString.
>
>I missed an obvious case. One of the outputs of LDAPprep is failure.
>Failure isn't a legal value of any input to LDAPprep.
>
>It disturbs me that LDAPprep can fail on syntactically correct input as this
>can give rise to ugly situations in the directory. If I add a new attribute with
>a single value to an entry then there is no need to call on LDAPprep because
>there is no need for any attribute value comparisons. If it so happens that
>the single attribute value contains character sequences that cause LDAPprep
>to fail then I cannot subsequently add other attribute values because the
>comparison of a new value to the existing value will always fail. Likewise,
>I cannot subsequently remove the single value because the comparison of the
>value in the modify operation to the existing value will also fail.
>
>There are implications for sorting as well.
>
>Regards,
>Steven