Re: New text: Attributes with no equality matching rule

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

Kurt D. Zeilenga writes:
> To address this issue, I suggest the following changes be made
> to [Models]:
> 
> Delete from 2.3 the sentence:
>   If the attribute type is defined with no equality matching rule,
>   two values are equivalent if and only if they are identical.

No, keep the definition of equivalence.  Equivalence is not used for
evaluating AVAs and so on, but to ensure that no values of an
attribute are equivalent, and that values equivalent to the stored
value is returned:

- last sentence of the paragraph above your suggested change:

  No two values of an attribute may be equivalent.

- last sentence of section 2.3:

  A 'givenName' attribute cannot hold both "John" and "JOHN" as these
  are equivalent values (...)

- last sentence of 6.1 (Preservation of User Information):

  And where a server is unable (or unwilling) to
  preserve the value of user information, the server SHALL ensure that
  an equivalent value (per Section 2.3) is returned.

- last paragraph of [Protocol] 4.1.7 (Attribute and PartialAttribute):

   No two attribute values are equivalent as described by Section 2.3 of
   [Models]. (...)

- [Protocol] 4.10 (Compare Operation):

This is the only one I can find which must be fixed, I suggest
s/is equivalent to/matches/, s/non-equivalent/FALSE/:

   The resultCode field is set to compareTrue, compareFalse, or an 
   appropriate error. compareTrue indicates that the assertion value in 
   the ava field is equivalent to a value of the attribute or subtype 
   (according to the attribute's EQUALITY matching rule). compareFalse 
   indicates that the comparison of the assertion value in the ava field 
   and the values of the attribute or subtype resulted in an Undefined 
   (Section 4.5.1) or non-equivalent match. 

> Add after first paragraph of section 2.5.1:
> (...)

Looks good, except I suggest:

>     - attribute value assertions

..."(such as matching in filters and Compare operations)"

>       using values of such a type
>       cannot be performed.

...because at that point, [Models] hasn't said what AVAs actually do.


> I note that I didn't say anything about syntax checking of
> values as this is already covered in section 2.5.4.

Not sure what you mean here, but it should probably be mentioned
somewhere that LDAP differs from X.501(1993) section 12.4.5a in that it
can perform syntax checking for attributes without EQUALITY matching
rules.

Also, you might update this statement in 2.5.4 (Attribute Values)
to mention that the name attributes also need EQUALITY rules:

  Only attributes whose descriptions have no options can be used for
  naming.


Finally, this might be copied to [Protocol] 4.6 (Modify Operation):

>     - individual values of a multi-valued attribute cannot be
>       added or deleted;

(...if the attribute has no EQUALITY matching rule.)

BTW, that is actually stricter than rfc2251, which only forbids
_deletion_ of individual values, not addition.

-- 
Hallvard