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

Re: Attributes with no equality matching rule

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.