On Wed, 2007-09-12 at 13:06 -0500, David Young wrote:

> Solution 2: increase the radiotap version number, and start over from
>         bit 0.  Now we need a "legacy" parser for v0, 0 <= bit <= 13,
>         and a "next gen" parser for v1.  No v0 header with bits >=
>         14 set can be interpreted without ambiguity.
> 
>         2a: adopt all of the legacy presence bits 0 through 13 in v1
>         2b: adopt some of the legacy presence bits in v1
>         2c: start from scratch for v1

Personally, I favour solution 2a as it allows us to easily port parsers
and even share code, but before we do that, we need a good way to allow
vendor-specific extensions. I've been thinking that a format with an
explicit length field like 802.11 information elements would have been
easier for this (think 802.11 vendor-specific IEs) but I'm sure we can
come up with a solution for vendor-specific fields, for example breaking
the "bit ordering" == "element ordering" for them and requiring them to
be last at all times or something similar.

johannes