Subject: Re: Attributes with no equality matching rule

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Mar 2004 02:23:53 +0100

Been thinking a bit more about this:

Kurt D. Zeilenga writes:
>At 11:19 PM 2/26/2004, Hallvard B Furuseth wrote:

>> Or - maybe implementations SHOULD behave as stated today, but MAY behave
>> like X.500?  Otherwise I think LDAP-X.500 gateways are in trouble.
> 
> I think it needs to be one way or the other. Otherwise clients
> designed for one way won't interoperate properly with servers
> designed for the other way.

OTOH, I don't think rfc2251 matches X.501 12.4.5 (a)/(b), so if we
change LDAP to conform to that, new and old LDAP implementations won't
interoperate properly.

I don't know about 12.4.5 (e).  What does it mean to "evaluate" an AVA?
The only meaning I can think of is the same as (d).

If I'm right that X.501 12.4.5a says that one can store a DN in a
telexNumber, I don't see how a combined X.500/LDAP server would do that:

If the DN is stored via DAP, it will be ASN.1-encoded, and I don't think
it contains any indication that it is a DN.  So if it is retrieved over
LDAP, it will have to be sent in ASN.1 form or some textual
representation of that.  While a DN stored over LDAP would have to be
stored as some arbitrarily chosen ASN.1 type, e.g. an OCTET STRING.

If an ASN.1 value is stored over DAP in an attribute without EQUALITY,
and that value cannot be interpreted as a value with the expected
syntax, the value which the server returns over LDAP might accidentally
conform to the LDAP textual syntax of the attribute's syntax, so one
cannot tell if the value is an ASN.1 value of wrong syntax or a value in
LDAP syntax.

-- 
Hallvard

---

From: Steven Legg <[email-masked]>
Date: Wed, 10 Mar 2004 14:17:55 +1100

Hallvard,

> The only meaning I can think of is the same as (d).

Case (e) does seem redundant, unless one takes a very literal interpretation
of (d) as applying only to compare operations.

> it contains any indication that it is a DN.

It doesn't.

 > So if it is retrieved over
> representation of that.

The obvious thing to do is to return it in BER encoded form with
the ";binary" attribute option.

 > While a DN stored over LDAP would have to be

12.4.5 (a) is a dumb rule. The ability to verify the syntax has nothing to
do with the presence or absence of an equality matching rule. It can also
be argued that 12.4.5 (a) is in contravention of the rules of ASN.1 since
a BER decoder would know the syntax and would be expected to verify that
the value conformed to that syntax.

While it would be possible to return an unverified BER value through LDAP using
the ";binary" option, it isn't a very useful thing to be doing, and there is
no way to return an unverified value through DAP if it was originally added
through LDAP. 12.4.5 (a) creates nasty problems for LDAP/X.500 interworking,
for no good reason, and should just be ignored.

However, the other cases make sense.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 19:36:09 -0800

>Been thinking a bit more about this:

I don't think there is much problem with adjusting [Models] to
be mostly consistent with X.501 here.  The only wrinkle I see
is the impact of LDAP syntaxes on things.   I should have new
text to offer soon and suggest we defer discussion until I'm
able to post that.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Mar 2004 21:07:48 -0800

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.

Add after first paragraph of section 2.5.1:
  If no equality matching is specified for the attribute type:     
    - the attribute (of the type) cannot be used for naming;            
    - individual values of a multi-valued attribute cannot be
      added or deleted;
    - attribute value assertions using values of such a type
      cannot be performed.

  Otherwise, the equality matching rule is to be used for the
  purposes of evaluating attribute value assertions concerning
  the attribute type.

I note that I didn't say anything about syntax checking of
values as this is already covered in section 2.5.4.  Also,
I didn't think it necessary to call out comparisons from AVAs
(given we describe compares in terms of AVAs).

Comments?

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Mar 2004 22:09:58 +0100

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

> (...)

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.

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

>     - individual values of a multi-valued attribute cannot be

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Mar 2004 14:26:10 -0800

>  No two values of an attribute may be equivalent.

I actually added the "no equality rule" sentence above
specifically to address issues of creation of an attribute
with multiple-values, not to address issues of individual
value addition/creation nor AVA evalation.

So, I suggest moving the paragraph break up one sentence
and to keep the above sentence.  That is, create a paragraph
that reads as follows:

  No two values of an attribute may be equivalent.  Two values are
  considered equivalent only if they would match according to the
  equality matching rule of the attribute type.  If the attribute
  type is defined with no equality matching rule, two values are      
  equivalent if and only if they are identical.  

>- [Protocol] 4.10 (Compare Operation):

I have no problem with your [Protocol] suggestions.

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

Instead:
  (such as matching in search filters and comparisons)

(I rather avoid use of the term "operations" when discussing
the abstract data model.)

>can perform syntax checking for attributes without EQUALITY matching

I was noting that I did not make add a specific statement about
syntax statement as section 2.5.4 already said:
  Attribute values conform to the defined syntax of the attribute.

If you could offer specific wording to call out the difference,
I'd appreciate it.  Right now, all the wording I've thought of
is a bit too intrusive.

>  Only attributes whose descriptions have no options can be used for

Suggest:
   Only attributes whose types have an equality matching rule
   and whose descriptions have no options can be used for naming.

or it may be better to reword this as two sentences, each of
which excludes a set of attributes.

>_deletion_ of individual values, not addition.

Well, if you consider that rfc2251 said that servers MUST
act in accordance with X.501, one can view RFC 2251 as just
not reiterating all the restrictions that are enforce.
I intend to categorize this change (in the Changes since
appendix) as simply addressing a technical omission.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 11 Mar 2004 18:05:16 +0100

>   equivalent if and only if they are identical.  

Fine.

>>it should probably be mentioned

Never mind, such a statement about a single difference seems rather
pointless.  A section with a list of significant differences from X.500
among the X.500-features that LDAP supports would be useful, but I'm not
volunteering to write it:-)

> which excludes a set of attributes.

The single sentence looks fine to me.

-- 
Hallvard