On Tue, 2004-04-13 at 16:09, Jefferson Ogata wrote:
>
> Something keeps bugging me, and I just want to throw it out there for
> the mad dogs to tear into little bloody pieces:
>
> Given all the desirable options people are looking for in this, and the
> need for future growth, I think we should seriously consider an
> XML-based format. Besides making it easy, format-wise, to include many
> optional features and types of metadata, programs could also embed
> decoded frame and protocol information in appropriate elements, right
> within the capture file.
[xml snipped]
> Yes, fully fledged decoded captures would use a lot of extra disk, but a
> raw no-frills capture could be recorded with maybe only 50% or so overhead.
>
> Processors using xslt or custom code could pull out just what they're
> interested in using XPath expressions. Decoders for specific application
> protocols could be written as filters to produce decoded elements in the
> output XML.
>
> And so on... mull it over for a minute before you start shredding.
Are you suggesting an xml-based pcap, or xmlified tcpdump output?
If you mean the former, I think the problem with this approach is that
in order to be able to write out a file in the first place, the
structure of the packet content has to be understood by libpcap (so that
it knows to write "<ip vers='4' hlen='20' ... flags='0x04' ...
proto='17'>" etc) -- then the question becomes what to do with unknown
protocols etc.
I think what you're proposing should be provided by an xmlified tcpdump,
but not the capture library.
Regards,
Christian.
--
________________________________________________________________________
http://www.cl.cam.ac.uk/~cpk25
http://www.whoop.org
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
