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

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>>> 2.2. Map
>>>
>>>  All other control code points (e.g., Cc) or code points with a control
>>>  function (e.g., Cf) are mapped to nothing.
>>>
>>>  ZERO WIDTH SPACE (U+200B) is mapped to nothing.  All other code points
>>>  with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
>>>  Zp) are mapped to SPACE (U+0020).
>>
>>Can you list these (mostly as character ranges, I hope), or are there
>>too many of them?
> 
> I could.  But I prefer to say it once than twice to avoid possible
> inconsistencies.  I am not adverse to adding an informative mapping
> table as an appendix.  Would that adequately address your concern?

That's fine.

>>For syntaxes/matching rules that expect non-empty strings, character
>>removal in step 2.2 can change a valid (non-empty) string to an invalid
>>(empty) one.
> 
> If either the presented or stored values are mapped to empty
> strings, then the match is Undefined.

Well, that's exactly my problem.  I think invalid strings should not be
inserted in the directory, and valid strings should compare as true or
false.  I don't like valid strings that do not compare as true or false.

I would't have a problem if non-empty strings that are mapped to "" were
invalid so they couldn't even be inserted in the directory.  But that
looks like another big can of worms, I don't think we want to go there.

> I don't see that as being much of a problem, especially since
> caseIgnoreIA5Match("",X) can be argued should behave just like
> caseIgnoreMatch("",X)...  evaluated to Undefined.

But it isn't "" which is compared to X.  It's "<SOFT HYPHEN>" or
something.

>>If that happens, I suggest a SPACE should be inserted for
>>matching rules where space can be insignificant.
> 
> I think this would be bad as caseIgnoreMatch(""," ") would
> evaluate to TRUE not Undefined.

No, I did not mean "" to map to " ".  Only insert a space if a non-empty
string would map to an empty one.

>>For the same reason,
>>
>>> 2.6.1. Insignificant Space Removal
>
> I suggest combining the statement with the previous paragraph:
>
>    A string consisting entirely of spaces is to be replaced with a
>    string of exactly one space.  Otherwise, the following spaces are
>    regarded are to be removed:

Fine.

-- 
Hallvard