Olivier LENORMAND wrote:
In this case, it's just that I never imagined that the "show" field was
not completed, so the lazy man I am used it while parsing the XML export
in order to avoid decoding the value field by myself.
Note that the "show" field doesn't, as far as I can tell, show up in the
current PDML and NetPDL spec in sense we're currently using it:
http://www.nbee.org/Docs/NetPDL/PDML.htm
which describes PDML and refers to the Field Visualization Variables in
NetPDL:
http://www.nbee.org/Docs/NetPDL/NetPDLVisualization.htm#NetPDLAssociatedData
which indicates that there's a "showvalue" field - which "contains the
field value in a 'printable' form". This isn't necessarily the
displayed text in the packet detail pain; for example, that section
seems to imply that for a field with a value_string table, i.e. a field
whose numerical value isn't the only value displayed, and where
particular numerical values have particular text strings associated with
them and the text string is displayed as well (the example they give is
the type of an ICMP message), the "showmap" field contains the text string.
Note, though, that the "printable" form of a field value might depend on
the field in ways that would require that a script reading PDML have to
know what particular field it's parsing *and* perhaps what version of
what application generated the PDML. Given that, decoding "value" might
be the best idea, as it's just raw hex data, which would only depend on
the version of the application if some versions of the application have
a bug and put the *wrong* hex data out.
