[Date Prev][Date Next]
RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- To: "Hallvard B Furuseth" <email@example.com>, <ietf-ldapbis@OpenLDAP.org>
- Subject: RE: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
- Date: Wed, 25 Jun 2003 11:56:51 +1000
- Content-class: urn:content-classes:message
- Thread-index: AcM6iD8ABrKf+vfLS9CyIYTwhPrhyAANHpjQ
- Thread-topic: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
Surely you can't do strprep on PrintableString? The choice of characters is so limited that there can't be any translation?
From: Hallvard B Furuseth [mailto:firstname.lastname@example.org]
Sent: Wednesday, 25 June 2003 05:29
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
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
Finally, there is no section 2.6. Sections 2.6.* should be 2.5.*.