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

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

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

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

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

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

-- 
Hallvard