Re: [Models] An attribute value should be equal to self

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

At 07:24 AM 3/8/2005, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 04:13 AM 3/8/2005, Hallvard B Furuseth wrote:
>>>> In absence of a guarantee that R( X, X) is always TRUE,
>>>> the [Models] statement in necessary.
>>>
>>>Necessary for what?
>>
>> To ensure that one can delete by value any and all values
>> added by value.
>
>That's useful, but not necessary. One can delete the value by replacing
>the attribute with all values but the one being deleted.

That would require the user to know all those values.

Also, consider the implications in naming:

If a client adds:
  dn: cn=<REPLACEMENT CHARACTER>,dc=example,dc=com
  objectClass: object
  cn: <REPLACEMENT CHARACTER>

where <REPLACEMENT CHARACTER> is the replacement character, a
prohibited character.  How is a client to modify this entry?

>Just as being
>able to store any UTF-8 string is useful but not necessary.  I think the
>latter is far more important.

Any UTF-8 string can be stored in the DIT.  One just has to use an
attribute type with an appropriate syntax and equality matching rule.

caseIgnoreMatch (or caseExactMatch) + Directory String is not an
appropriate combination where the application desires to store
strings of arbitrary Unicode code points.

That is, for this use, one should specify a "Unicode Code Point
Match" equality rule for use with Directory String.... or just
use octetStringMatch and octetStrings (and state a requirements
be constrained to UTF-8).

>> Even though introduction of LDAPprep made apparent the need for
>> this, this is not just about LDAPprep,   It's about any rule where
>> there is any X where R(X,X) is Undefined.

My point here is that LDAPprep-based equality rules are not
the only rules which may exhibit the behavior that for some
X, R(X,X) is Undefined.   That is, even if LDAPprep was
changed such that R(X,X) was TRUE for all X, the [Models]
statement would be appropriate to address the general issue.

The only other way to address the general issue is to require
that all equality rules have the property that R(X,X) is
TRUE for all possible values of X.  That is, IMO, a far more
a problematic requirement.

>Where?

anywhere.

>It mentions interoperability and security in [Prep] 1.2.  I
>don't see where it says that error returns from LDAPprep is necessary
>for security, but for all I know it may be.  Nor does it mention why
>being able to name individual values is more important than being able
>to have any UTF-8 string in a Directory String.  I never agreed that
>interoperability for values that fail LDAPprep, when interoperability
>means "you can't use them at all", is more important than being able
>to at least use them locally - and that was before we discovered just
>how many problems there were with being able to store them at all.

LDAPprep is still in development.  Maybe we'll reach consensus
that for all X, R(X,X) is to be TRUE.   But regardless of whether
we reach that consensus, X.500/LDAP allows (IMO) there to be
other rules where for some X, R(X,X) is Undefined.  And, because
of this, it is appropriate for [Models] to state the restriction
because allowing X as a value of an attribute where R(X,X) is
not TRUE is quite problematic.

Kurt