Re: protocol: searches and subtypes

Yes, it matters. Do you think the wording is confusing? The way I
intended to word it would instruct one to use the matching rule
associated with the attribute type or subtype which is being evaluated.
 
Jim

>>> "Kurt D. Zeilenga" <[email protected]> 3/10/05 9:31:34 AM >>>
At 08:56 AM 3/10/2005, Jim Sermersheim wrote:
>I can look at that (though it may be better the way it is). Here's a
>typical sample of the new text:
> 
>4.5.1.7.3 SearchRequest.filter.greaterOrEqual
>
>The matching rule for a greaterOrEqual filter is defined by the
>ORDERING matching rule for the attribute type or subtype. The filter
is
>TRUE when the ORDERING rule returns FALSE as applied to the attribute
or
>subtype and the asserted value.

Does it matter that the rule on the subtype could be different than
that on the type? or that the subtype could have a ordering rule
and the type none?

- Kurt




>Jim
>
>>>> Hallvard B Furuseth < [email protected] > 3/9/05 11:13:44
PM
>>>>
>How about factoring the former out to SearchRequest.filter?
>
>Jim Sermersheim writes:
>> Will update all filter definitions and the definition of the
>selection
>> list to reflect this.
>>
>>>>> Hallvard B Furuseth < [email protected] > 2/28/05 7:13:54
>AM
>> I believe protocol-30 section 4.5 should say
>>
>> - that subtypes of SearchRequest.attributes are returned as well
>> as the listed attributes,
>>
>> - that subtypes of an attribute type in a filter will be used as
>> well as the attribute type itself.
>>
>> It says so about SearchRequest.filter.<present, approxMatch>.
>> RFC2251 says it about SearchRequest.filter.present only.
>
>-- 
>Hallvard