Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep

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

At 12:44 PM 6/25/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> I'd argue, for attributes which have an EQUALITY RULE, that only
>> values which EQUALITY(value,value) is True can be added to the
>> directory.
>
>This diverges from X.500, doesn't it?
>Also, not that I mind, but it sounds a little like LDAPv4 to me...

Well, it might be a bit divergent.  I'd have to carefully
review X.501 to see what it says here.

So let's reconsider the options here:

>[Models] 2.3 (Structure of an Entry) says:
>  No two values of an attribute may be equivalent.
>  Two values are considered equivalent if they would match according to
>  the equality matching rule of the attribute type.
>
>So what happens if I attempt to give an attribute in an entry two valid
>values that map to "" and thus match as undefined?  Are the values
>equivalent, or not?
>
>- If they are not equivalent, then we can put several "<SOFT HYPHEN>"
>  values in one attribute in an entry.

Obviously that would be counter to X.501.

>- If they are equivalent, then we can only add the value "<SOFT HYPHEN>"
>  if the attribute has no other values.  After that, an attempt to add
>  _any_ value will fail.

This, I believe, is consistent with X.501.  That's how the matching
rules behave.

When I first read your suggestion, I assumed you wanted to replace
"" with " ".  I think I am fine with your suggestion that if the
input to the mapping step is non-empty and the mapping would result
in an empty string, the output is instead " ".

This handles the map to "" issues, but it does nothing to allow
both "foo<REPLACEMENT CHARACTER>bar" and "barfoo" to co-exist as
values of CN.  Personally, I don't think "foo<REPLACEMENT CHARACTER>bar"
should be an allowed value of CN.

Anyways, to implement this suggestion, I think I rather say that the
output of the translation step must be non-empty (if empty,
the preparation fails, match is Undefined).  Remove the prohibition
of empty strings in the prohibit section and insert the space during
the insignificant space removal step.   My rationale for doing it
this way is that mapping and prohibition should be done on a
character-by-character basis and string-wise things should be
done either in first or last steps.

Kurt