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

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Nov 2004 13:18:13 -0700

>>> Hallvard B Furuseth <[email-masked]> 11/8/04 5:59:28 AM
>>>
<snip>
>> 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.
 
>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)
<snip>
 
Jim

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Nov 2004 21:31:39 +0100

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

>> filters just return Undefined.
>  

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