On Wed, 2003-09-24 at 02:04, Fulvio Risso wrote:
> Hi.
> Some comments.
>
> 1. The syntax defined in Analyzer is more complete (i.e. it has more info
> than the one you're proposing, like the position into the packet, the length
> of the field). That's just because it has been defined some months ago.
>
> 2. There's no way to know if the value of a given field is formatted in hex,
> bin, dec, asci... (analyzer uses the synxtax defined into another XML file,
> the NetPDL one).
>
> 3. Although a field named "eth.dst" makes sense, this field is contained
> into a protocol that is called "eth". So, it should be enough calling it
> "dst".
I've given this much thought, and I'm still on the side of providing
"complete" field names. John McDermott pointed out the same thing to me
in a private e-mail, and I described to him why I like "eth.dst" instead
of "dst" contained within an "eth" parent.
I can see why one would want the abbreviated field name:
1. It fits better with the XML idea of a tree of elements, i.e., with
the parent/child relationship of elements.
But, on the other hand:
1. The field name within ethereal really is "eth.dst"; it is not "dst"
which is then registered under a protocol named "eth".
2. There is no restriction in Ethereal that a field named "xxx.yyy" must
be located in a branch under the protocol "xxx". A field "xxx.yyy" can
be placed in a branch under protocol "zzz". There used to be an implied
restriction because of the way the display filter engine worked; it used
to check for fields only under branches of the protocols for which they
were registered. But this caused a problem for NLM:
http://www.ethereal.com/lists/ethereal-dev/200008/msg00071.html
That restriction in the display filter engine was removed.
3. It's more natural for someone writing a script to parse the XML to
use the same names that are used in Ethereal's display filter engine. My
Python code might look like:
fields = frame.get_node("eth.dst")
That's more "Ethereal-like" than:
eth = frame.get_node("eth")
dst = eth.get_node("dst")
Of course, the latter is more XML-like. :)
>
> 4. The Hexdump, altough it makes sense, it can be obtained by "appending"
> the content of each field one after the other.
Actually, the hexdump in this case comes from the "Data" field/protocol.
It's the "rest of the packet" that Ethereal doesn't analyze. So it needs
to be provided, but perhaps just the bytes, and not the offset counter
or the ASCII representation of the bytes.
Do you do anything like this in PDML?
>
> 5. The 'general' syntax looks similar, so there is space for collaborations
> in there.
>
> What we can do, if you agree, is to define a general format for generating
> the complete decoding of the packet, in XML.
> If you're interested in that, we may move our discussions out of the mlist.
>
> Currently, we're using the PDML (the one you can find in attachment) for
> generating the views into Analyzer. In other words, a library creates the
> PDML file, then Analyzer reads this file and it uses the info contained in
> it to generate the 'treeview' and 'dumpview' of the captured packet.
>
I've read your PDML spec at
http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm
and yes, we're very close. We should work to provide the same format of
output; I can change my output to be very close to PDML.
> fulvio
>
--gilbert
