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" <Kurt@OpenLDAP.org> 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 < h.b.furuseth@usit.uio.no > 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 < h.b.furuseth@usit.uio.no > 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 |