[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
At 12:28 PM 6/24/2003, Hallvard B Furuseth wrote:
>> 2. String Preparation
>> The following six-step process SHALL be applied to each presented and
>> attribute value in preparation for string match rule evaluation.
>
>Not to octet strings. Do they count as _string_ match?
The algorithm is intended to apply (as specified in other documents)
to character string matching. I suggest inserting the word 'character'
before 'string' in the above sentence and likewise in a few other places.
>> 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?
>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. 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.
>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.
>For the same reason,
>
>> 2.6.1. Insignificant Space Removal
>> A string consisting entirely of spaces is equivalent to a string
> ^^^^^^^^^^^^^^^^
>> containing exactly one space.
>
>This doesn't say anything about how to translate the string.
>I think it should be "... is _translated to_ a string containing...".
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:
>2.6.2 (numericString) and 2.6.3 (telephoneNumber) should also re-insert
>a single space if they would translate a non-empty string to an empty
>one, since these syntaxes also expect a non-empty string.
>That is, I assume 'PrintableString (SIZE(1..ub-telephone-number))' in
>the definition of the Telephone Number syntax means one or more
>character.
Okay.
>Finally, there is no section 2.6. Sections 2.6.* should be 2.5.*.
Yes.