Hannes,
> | I don't feel that tcpdump output should be frozen forever; some changes are > | appropriate. But the changes I've seen have seemed indiscriminate. Again, > | why put a comma after the TCP flags? Why reorder the TCP fields relative > | to one another? Why change the way 'cksum' is spelled? Why print out the > | checksum when it's valid? Why not leave the IP addresses at the beginning > | of the line? Abstract reasons, about the physical order, are not good > | enough. > > again consistency ... we use the "cksum 0x1234 (correct)" style in > many dissectors; > > print-vrrp.c > print-udp.c > print-tcp.c > print-isoclns.c > print-ip.c > print-icmp6.c > print-icmp.c
Most/all of which changed to support the new format.
> printing _all_ elements (checksum, ip ttl, dhcp options) not just som > based on content makes actually script marsing much more easy ... > many firewall guys expressed concerns that they want to see all the > fields [IP ID] for detecting handcrafted packets etc ....
So what about the other points?
It seems like you are not willing to change the different, internally consistent format you've come up with, even in minor ways, to satisfy backward compatibility or user expectation. Fine, if the developer consensus is that no one else cares about this, and that a format-selection flag would be a bad idea.
Please settle on a final format soon, and change the major version number.
A style guide sounds fine. But the principle that scripters want is probably "I can depend on the output format remaining stable". This is more important than XML vs. non-XML, consistency between protocols, whatever else. (Constantly-shifting XML isn't much better than constantly-shifting text.)
Two of the ways to get this stability would be:
(1) define some sort of textual tag/value format or punctuation so that new elements can be ignored. (For example, "proto 6 {TCP}" might follow this rule better than "proto: TCP (6)", since you could tell scripters that anything in {curly braces} was a comment, and comments can change between releases.)
(2) guarantee that minor version number changes will not change the format in major ways.
Your changes don't follow (1) so you should change the version number to satisfy (2).
Many of your changes, particularly around punctuation ("proto: TCP (6)" vs. "proto 6", ".," vs ".", "win 84314" vs. "win: 84314"), still seem gratuitous. I just wish you'd take backwards compatibility more seriously.
Eddie - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
