Re: protocol: searches and subtypes
"Kurt D. Zeilenga" <[email protected]>
| Newsgroups | gmane.ietf.ldapbis |
|---|---|
| Message-ID | <[email protected]> |
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