Wireshark-bugs: [Wireshark-bugs] [Bug 2226] Mismatching </proto> element in a PDML explort
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2226
--- Comment #7 from Rene Baumann <Rene.Baumann@xxxxxxxxxxxxxx> 2008-02-01 08:07:50 GMT ---
>Any changes may upset someone whose application depends upon the status quo.
>We could:
>
>- tighten up the proto.h functions to not allow fields to be added outside of
>protocol trees, and fix violations (although I expect the checking could only
>take place at run-time, so it may take a while to pick them all up). I did
>have a go at adding a second (protocol) tree to the function
>decode_tcp_ports(). If it failed to find a dissector to call, it would use the
>2nd (existing protocol) tree to add the data field inside the existing
>protocol. This worked OK for TCP iteself and msproxy, but not easily for the
>HTTP dissector.
>
>- make the 'data' dissector print as a protocol instead of as a field. This
>would help a lot.
>
First the not well-formed output should be fixed.
Otherwise it doesnt make sense to create a output with pdml.
Then the best idea think is to define a DTD together. This DTD should show how
it works and gives a good fundament.
Then everbody knows how to work with the output correctly.
Especially I think of this specification:
http://gd.tuwien.ac.at/.vhost/analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm
I wrote a first DTD and attached it to this bug.
Have a look at it.
>I don't have any applications to break. It'd be good to hear from people who
>rely upon the output.
I'm relying on it.
My applcation breaks only because of the not well-formed pdml output.
>- in the PDML output, keep track of the level, and if we attempt to write out
>fields at level 0, wrap them up in a fake protocol
That would be nice...
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
