Re: protocol: searches and subtypes

At 11:24 AM 3/10/2005, Jim Sermersheim wrote:
>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.

I am fine with the current wording and specified semantics.

> 
>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 < <mailto:[email protected]>[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 < <mailto:[email protected]>[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