[Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxxx>]

I've been looking through the dfilter code a bit, and would like to 
propose some fairly substatial changes.

Currently we have ranges for only FT_BYTES type fields. We do not 
have non-ranged relations for FT_BYTES.  I would 
in general say that ranges would be useful for any variable 
of a type which represents a sequence .  This would include FT_STRING,
FT_ETHER, FT_IPv4, FT_IPv6, and FT_BYTES.  Of these I would say minimally 
we should extend ranges to FT_STRING.  I would also like to see FT_BYTES 
comparable whole in the same sort of way that FT_STRINGS are.

Currently ranges are of one of two forms: 

1)	[i:j]
	Where i is the offset and j is the length.

or

2)	[i ] 
	Where i is the offset and the length is implied to be to 
	the end of the RHS value given (or the length of the field 
	types being compared).  


The problem with 2 is that the range operators [] doesn't 
actually bind to the LHS variable to which it appears to be 
attached, but rather binds to both the LHS (through the offset) and 
to the RHS (through the implied length of the RHS).
I find this quite counter intuitive.  Second it would 
be nice to use the range operator [] to be able to specify a 
single particular element in a sequence for use in a relation.
For example it would be nice if 

bootp.hw.addr[3] 

actually refered to the element at offset 3 in the sequence of bytes
making the variable boot.hw.addr, instead it appears to compare whatever the 
RHS value in the relation is to the bootp.hw.addr variable, starting at 
the third element and continueing out to the length of the RHS.  This
seems highly counterintuitive to me.

I would propose a move towards a python like standard for ranges through 
the following:
1)	Ranges of the form [i] denote the element of the 
	sequence at offset i, so 
	bootp.hw.addr[3] 
	would refer to the third byte in the bootp.hw.addr variable.

2)	Ranges of the form [i:] denote all elements in the sequence  from
 	the offset i to the end of the sequence, so 
	bootp.hw.addr[3:]
	would refer to the all bytes in the bootp.hw.addr variable 
	from the offset 3 to the last byte(inclusive) in the bootp.hw.addr 
	variable. 

3)	Ranges of the form [i:j] denote the elements of the sequence from 
	the offset i to the offset j-1 (if j is positive).  So 
	bootp.hw.addr[3:6] 
	would denote the byte sequence  from the byte at offset 3 
	bootp.hw.addr to the fifth byte (inclusive) of the bootp.hw.addr
	variable.

4)	Ranges of the form [i:-j] where j is positive will denote 
	the elements of the sequence from offset i to an offset 
	j from the END of the sequence.  So 
	bootp.hw.addr[3:-1] 
	would refer to the byte sequence from the byte at offset 3 
	to the next to last byte in the sequence.  So given a
	bootp.hw.addr with a length 6, bootp.hw.addr[3:-1] would be 
	equivalent to bootp.hw.addr[3:5]

5)	Ranges of the form [-i:j] will simply denote offset into 
	the bytes before the variable field in the frame as they 
	currently seem to do.

6)	Range will be bound to the variable directly to their left.
	There will no longer be binding partially to the variable 
	in a relation and partially to the value in a relation. 

7)	Variables for sequence types without any range operator 	
	will refer to the entire sequence making up that variable.
	So
	bootp.hw.addr
	will refer to all bytes in bootp.hw.addr and any relation 
	will be between all bytes in bootp.hw.addr and whatever 
	else is being compared to.  So 
	bootp.hw.addr == 0:8:20:A:A:A
	would only be true for proto_trees for which bootp.hw.addr 
	was exactly 0:8:20:A:A:A

8)	All variables which are composed of sequences shall filter 
	according to this standard (or whatever standard comes out 
	of the ensuing disagreement from this email).  Consistency
	is important.  This definitely includes FT_STRINGS, FT_BYTES,
	and probably includes FT_ETHER, FT_IPv4, and FT_IPv6.  Suggestions 
	as to other types which people consider a sequenced type 
	which they think should have these principles applied to them
	would be welcome.

I think that this set of actions would significantly clean up the 
filtering process and how it deals with sequenced types.  I am willing to 
code towards this, but there are substantial enough changes proposed 
here that I didn't want to make them without at least putting out a 
RFC so people could raise complaints.

Ed