diff --git a/doc/README.xml-output b/doc/README.xml-output index 3fa6d2b7a4..1ab5f3f9c6 100644 --- a/doc/README.xml-output +++ b/doc/README.xml-output @@ -12,11 +12,8 @@ working on Analyzer. The specification was found at: http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm -That URL is not working any more, but a copy can be found at: - -http://gd.tuwien.ac.at/.vhost/analyzer.polito.it/docs/dissectors/PDMLSpec.htm - -or at the internet archive: +That URL is not working anymore, but a copy can be found at the Internet +Archive: https://web.archive.org/web/20050305174853/http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm @@ -24,16 +21,16 @@ This is similar to the NetPDL language specification: http://www.nbee.org/doku.php?id=netpdl:index +The domain registration there has also expired, but an Internet Archive +copy is also available at: + +https://web.archive.org/web/20160305211810/http://nbee.org/doku.php?id=netpdl:index + A related XML format, the Packet Summary Markup Language (PSML), is also defined by the Analyzer group to provide packet summary information. The PSML format is not documented in a publicly-available HTML document, -but its format is simple. Wireshark can export this format too. Some day it -may be added to tshark so that "-Tpsml" would produce PSML. - -One wonders if the "-T" option should read "-Txml" instead of "-Tpdml" -(and in the future, "-Tpsml"), but if tshark was required to produce -another XML-based format of its protocol dissection, then "-Txml" would -be ambiguous. +but its format is simple. Wireshark can export this format too, and +tshark can produce it with the "-Tpsml" option. PDML ==== @@ -41,7 +38,9 @@ The PDML that Wireshark produces is known not to be loadable into Analyzer. It causes Analyzer to crash. As such, the PDML that Wireshark produces is labeled with a version number of "0", which means that the PDML does not fully follow the PDML spec. Furthermore, a creator attribute in the -"" tag gives the version number of wireshark/tshark that produced the PDML. +"" tag gives the version number of wireshark/tshark that produced the +PDML. + In that way, as the PDML produced by Wireshark matures, but still does not meet the PDML spec, scripts can make intelligent decisions about how to best parse the PDML, based on the "creator" attribute. @@ -96,14 +95,26 @@ The "" tag show - the representation of the packet data ('value') as it would appear in a display filter. + +Deviations from the PDML standard +================================= +Various dissectors parse packets in a way that does not fit all the assumptions +in the PDML specification. In some cases Wireshark adjusts the output to match +the spec more closely, but exceptions exist. + Some dissectors sometimes place text into the protocol tree, without using a field with a field-name. Those appear in PDML as "" tags with no 'name' attribute, but with a 'show' attribute giving that text. +Some dissectors place field items at the top level instead of inside a +protocol. In these cases, in the PDML output the field items are placed +inside a fake "" element named "fake-field-wrapper" in order to +maximize compliance. + Many dissectors label the undissected payload of a protocol as belonging -to a "data" protocol, and the "data" protocol usually resided inside -that last protocol dissected. In the PDML, The "data" protocol becomes -a "data" field, placed exactly where the "data" protocol is in wireshark's +to a "data" protocol, and the "data" protocol often resides inside +that last protocol dissected. In the PDML, the "data" protocol becomes +a "data" field, placed exactly where the "data" protocol is in Wireshark's protocol tree. So, if Wireshark would normally show: +-- Frame @@ -143,8 +154,24 @@ In PDML, the "Data" protocol would become another field under HTTP: +In cases where the "data" protocol appears at the top level, it is +still converted to a field, and placed inside the "fake-field-wrapper" +protocol, just as any other top level field. + +Similarly, expert info items in Wireshark belong to an internal protocol +named "_ws.expert", which is likewise converted into a "" element +of that name. + +Some dissectors also place subdissected protocols in a subtree instead of +at the top level. Unlike with the "data" protocol, the PDML output does +_not_ change these protocols to fields, but rather outputs them as "" +elements. This results in well-formed XML that does, however, violate the +PDML spec, as "" elements should only appear as direct children of +"" elements, with only "" elements nested therein. + Note that packet tag may have nonstandard color attributes, "foreground" and "background" + tools/WiresharkXML.py ==================== This is a python module which provides some infrastructure for