Roman Rybalko wrote:
Have a schema:
olcAttributeTypes: ( 2.999.777.1.1.1.3 NAME 'orderingInteger' DESC
'Integer with ordering' EQUALITY integerMatch ORDERING
integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: ( 2.999.777.1.1.2.16 NAME 'timeInteger' DESC 'Integer
time representation' SUP orderingInteger )
olcAttributeTypes: ( 2.999.777.1.1.2.17 NAME 'Mailbox' DESC 'Mailbox
name' SUP info )
olcAttributeTypes: ( 2.999.777.1.1.2.16.1 NAME 'timeIntegerYear' DESC
'Integer year representation' SUP timeInteger )
olcAttributeTypes: ( 2.999.777.1.1.2.16.2 NAME 'timeIntegerMonth' DESC
'Integer month representation' SUP timeInteger )
olcAttributeTypes: ( 2.999.777.1.1.2.16.3 NAME 'timeIntegerDay' DESC
'Integer day of the month representation' SUP timeInteger )
olcAttributeTypes: ( 2.999.777.1.1.2.16.4 NAME 'timeIntegerHour' DESC
'Integer hour representation' SUP timeInteger )
olcAttributeTypes: ( 2.999.777.1.1.2.16.5 NAME 'timeIntegerMinute' DESC
'Integer minute representation' SUP timeInteger )
olcObjectClasses: ( 2.999.777.1.2.3 NAME 'entry' SUP top STRUCTURAL MAY
( timeInteger $ timeIntegerYear $ timeIntegerMonth $ timeIntegerDay $
timeIntegerHour $ timeIntegerMinute ) )
Have a search:
(&(timeInteger>=1348900000)(timeInteger<=1349000000))
This search may return entries like:
timeInteger: 1347014897
timeIntegerYear: 2012
timeIntegerMonth: 9
...
The entry with timeInteger=1347014897 is obviously not in
[1348900000,1349000000] range, but it is matched because there are
another attributes in the entry with "SUP timeInteger", so
timeIntegerYear=2012 is matched the (timeInteger<=1349000000) filter part.
I'm looking for RFC that describes such behavior.
RFC4512 section 2.5.3.
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/