[Date Prev][Date Next]
Re: ITS#1998, zero-length attr vals
BTW, we need to do some work in the string preparation
area. One approach is to do away with UTF8StringNormalize
and put all the string preparation (excepting transcoding)
into UTF8bvnormalize. Presently we're removing extra
spaces (U+0020) before we've done mapping... which means
we might still have extra spaces.
Basically, I'm thinking we should have one normalizer
which handles not only case ignore/exact matching, but
numericString and telephoneNumber (which alter the
mapping step). Likely this can be done with more flags
and more core.
I should have draft-ietf-ldapbis-strpro ready soon...
At 05:42 PM 2002-08-05, Stig Venaas wrote:
>On Mon, Aug 05, 2002 at 05:26:56PM -0700, Kurt D. Zeilenga wrote:
>> At 05:00 PM 2002-08-05, Howard Chu wrote:
>> >Back to this issue again; the crash is actually an assert() because the
>> >result of normalizing a single space is a zero-length string. It seems
>> >we need to remove these asserts and return a failure code, or just accept the zero-length strings.
>> Or, fix the normalizer so that it does the right thing.
>> The right thing in this case (directory string) is to
>> normalize one or more spaces to one space.
>Not zero? Does that mean that zero-length directory string isn't
>allowed? If it is allowed, should a one space (or more) directory
>string be treated as different from a zero-length one?