On Oct 19, 2011, at 4:28 PM, Bill Meier wrote:
> No fixes required:
> FT_RELATIVE_TIME
> FT_FRAMENUM
> FT_PCRE
...because they're currently not supported by proto_tree_add_item(). FT_FRAMENUM never will be, and FT_PCRE is, I think, a type used only in filter expressions (a field cannot have that type), but, at some point, we'll probably support FT_RELATIVE_TIME in a fashion similar to FT_ABSOLUTE_TIME, at which point it'll require a byte order. There are no *current* calls that need to be fixed.
> TBD/ToDo:
> FT_ETHER Not yet fixed: Should always be ENC_NA ???
Yes. A MAC-48 address is just a sequence of 6 octets, so no byte order.
> FT_PROTOCOL Not yet fixed: Should be ???
ENC_NA. It's like FT_NONE.
