From: Ulf Lamping
| Hi List!
|
| It's sometimes confusing to distinguish between protocol fields
derived
| from the capture data and fields that are generated by Ethereal
while
| dissecting "from knowledge" (e.g. from context information).
|
| Example:
|
| In the DCE-RPC dissecting are some protocol fields generated by
| knowlegde from context, like a hint to the response in a request
packet,
| looking like.
|
| Response in frame: 10
|
| This means that the response PDU to the current one is in packet 10.
| This protocol field has no data representation inside the packet.
|
| From the DCE/RPC desegmenting, I got the idea to put some brackets
| (what's the correct english name for this brackets?) around the
Ethereal
| generated info, so this will look like:
|
| [Response in frame]: 1
There are parentheses, sometimes called brackets: ( )
There are brackets, sometimes called square brackets: [ ]
There are braces, somethimes called curly braces: { }
| I've checked in an example of this in the DCERPC dissector (but I
can
| easily remove it again, if others really don't like it).
|
|
| What do others think of the idea, to put this brackets around field
| names of Ethereal generated protocol fields in general?
It is a good idea to provide such a distinction between information
within the protocol packet and generated information.
Some other options:
a. Prepend or append an asterisk to the field name
b. Render the field differently (e.g., italics in Ethereal)
Once we have agreed on some output format we may first want to edit
the reassembly code as that will impact *all* dissectors that use
reassembly at once.
Regards,
Olivier
