Re: Attributes with no equality matching rule

[Steven Legg <steven.legg@adacel.com.au>]

Hallvard,

Hallvard B Furuseth wrote:
> 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).

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

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

It doesn't.

> So if it is retrieved over
> LDAP, it will have to be sent in ASN.1 form or some textual
> 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
> 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.

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