Re: absent matchingRule (was Re: protocol-27 comments #3)

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

Jim Sermersheim writes:
>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 11/8/04 5:59:28 AM
>>> If the matchingRule field is absent, the type field MUST be
>>> present, and an equality match is performed for that type.
>>
>>Which means just (:dn:=foo) is not allowed. Maybe the draft should
>>suggest that one can use (1.1:dn:=foo).
>  
> Well, what does (1.1:dn:=foo) mean? I think it means that this filter
> will always evaluate to undefined.

Looking at the description of dnAttributes under extensibleMatch in
4.5.1. Search Request, it returns TRUE if a DN attribute matches foo -
regardless of Undefined or False from the rest of the filter.  Though
maybe I'm just getting lost here - at the moment I can't see where the
draft says that matching an unknown attribute type returns Undefined,
and certainly not where it says that this overrides the dnAttributes
description.

>> Also, is it an error to violate this "MUST"? Most other invalid
>> filters just return Undefined.
>  
> My read is that this is a protocol violations (and other protocol
> violations in filters are not evaluated to undefiened, they return
> protocolError)

OK.  In that case I have a problem with the MUSTs for search requests
that it is not a protocol violation to violate, but I think we've been
there before.

-- 
Hallvard