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.