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

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Surely you can't do strprep on PrintableString? The choice of characters is so limited that there can't be any translation?

-----Original Message-----
From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
Sent: Wednesday, 25 June 2003 05:29
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep


RL 'Bob' Morgan writes:
> A reminder that the Last Call period on these drafts ends this Wednesday,
> June 25.

Whoops.  Thanks for the reminder.  I've been sitting on this for too
long:

I have some problems with ldapbis-strprep.  I posted some of them before
to the strmatch draft, but I don't think I got a reply.


> 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?


> 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?


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 that happens, I suggest a SPACE should be inserted for
matching rules where space can be insignificant.  I don't know what to
do about matching rules where space is always significant.

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...".

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.


Finally, there is no section 2.6.  Sections 2.6.* should be 2.5.*.

-- 
Hallvard