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

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

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.