Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0

[George Tsirtsis <tsirtsis at googlemail.com>]

Agreed, which is again why binary makes sense as the default.

George


On Wed, May 13, 2009 at 11:57 PM, Glen Zorn <gwz at net-zen.net> wrote:
> Hannes Tschofenig [mailto://Hannes.Tschofenig at gmx.net] writes:
>
>> Sorry to be unclear.
>>
>> There are two aspects:
>>
>> 1) How do you encode filters on the wire, i.e., when carried in your
>> favorite mobility protocol (or other protocol; does not really matter
>> that
>> much).
>>
>> 2) How are these filters implemented in a particular node?
>>
>> Now, for item (2) folks have come up with quite sophisticated
>> mechanisms
>> (typically dedicated languages that have an assembler like syntax) over
>> time
>> that are (a) highly efficient and (b) quite compact in the encoding. I
>> provide a reference to the BSD packet filter system but the work
>> obviously
>> did not stop in 1992.
>>
>> Now, ideally you would want to select a format for (1) that allows easy
>> conversion to the format used with (2).
>>
>> The problem now is that different implementations use different
>> languages.
>> So, it is quite likely that you will have to convert the stuff you get
>> via
>> (1) anyway to (2).
>>
>> So, my conclusion is that the format for (1) does not really matter
>> unless
>> you get to pick a format that is extremely close or equal to the format
>> used
>> by (2) for most of the implementations.
>>
>> This only matters if the translation from (1) to (2) is performance-
>> wise an
>> issue. I am not sure it really is and in that case you could as well
>> toss a
>> coin since it does not matter at all for the format for (1) is.
>>
>> Does this description make any sense?
>
> Total sense.  I'd just add that if we are to worry about performance issues
> at all they should be issues that we have some control over (i.e.,
> efficiency on the wire) rather than those we do not (for example, the
> algorithms used at either end to create or process the filters).
>
> ...
>
>
>