On 1/30/07, Mark H. Wood <[EMAIL PROTECTED]> wrote: > ASN.1 was designed specifically for that sort of thing.
Not really. ASN.1 is a standard description format for new protocols. It is not designed to, nor is it capable of describing arbitrary existing protocols. If a new encoding were arrived at, maybe, but you would probably end up needing extensions to ASN.1 as well. NetPDL or things like it are the way to do this. However, it is not realistic to think that you will never need to have hooks in the XML descriptors for custom code. For example, say Protocol X uses some funny encoding for a field that no one else uses (beyond just shifts and ORs of bits). Also the order in which decoding is done may be important. You can have one decode step at the beginning followed by a relatively normal packet disassembly. Sequence, iteration, algorithms, etc. are more naturally handled in code than XML document (that didn't stop the abomination that is XSLT though ;-) ). That's not a reason not to attempt this. A generic description would take you pretty far with most protocols and obviate most of the code in Ethereal dissectors, presumably making it easier to maintain (though it would probably take longer to load). Just make sure that hooks are provided to easily decode formats that were not considered. Perhaps the XML documents could be compiled during the build process to C structures and initialization code. -- John. _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev