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

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

At 02:18 PM 6/25/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 12:44 PM 6/25/2003, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>>>
>>>[Models] 2.3 (Structure of an Entry) says:
>>>
>>>So what happens if I attempt to give an attribute in an entry two valid
>>>values that map to "" and thus match as undefined?  Are the values
>>>equivalent, or not?
>>>
>>>- If they are not equivalent, then we can put several "<SOFT HYPHEN>"
>>>  values in one attribute in an entry.
>> 
>> Obviously that would be counter to X.501.
>> 
>>>- If they are equivalent, then we can only add the value "<SOFT HYPHEN>"
>>>  if the attribute has no other values.  After that, an attempt to add
>>>  _any_ value will fail.
>> 
>> This, I believe, is consistent with X.501.
>
>Well, if you say so.  Both the alternatives I listed sound weird to me.
>But perhaps this is the best we can do.
>
>> That's how the matching rules behave.
>
>Well, it's how LDAP (and X.500?) {will} _use_ the matching rules.
>If I understand you correctly, the part of [Models] 2.3 which I quoted
>should be changed to something like
>
>  If the attribute type has an equality matching rule, any two values of
>  the attribute must compare as false according to that matching rule.

Yes.

>> This handles the map to "" issues, but it does nothing to allow
>> both "foo<REPLACEMENT CHARACTER>bar" and "barfoo" to co-exist as
>> values of CN.
>
>Nor does it let "foo<REPLACEMENT CHARACTER>bar" to co-exist with _any_
>value, since since they would match as Undefined whatever the other
>value is.

Yes.

>> Personally, I don't think "foo<REPLACEMENT CHARACTER>bar"
>> should be an allowed value of CN.
>
>No opinion.  I don't even know what <REPLACEMENT CHARACTER> is.

You might want to consider all the other cases where the preparation
fails and hence the rule evaluation is Undefined.  There are many.

>> Anyways, to implement this suggestion, I think I rather say that the
>> output of the translation step must be non-empty (if empty,
>> the preparation fails, match is Undefined).  Remove the prohibition
>> of empty strings
>
>You mean, move the prohibition of empty strings from the Prohibit
>step to the Transcode step?

Yes.

>> in the prohibit section and insert the space during
>> the insignificant space removal step.