[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Attributes with no equality matching rule


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.