[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
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