[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
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.
- References:
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
- ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
- Re: ldapbis WG Last Call on ldapbis-syntaxes, ldapbis-strprep
- From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>