Is it better to have dissected and lost than never to have dissected at all?

[Michael Mann <mmann78 () netscape net>]

This question has probably been asked before, so I thought I'd at least put a Tennyson twist on it.

I started getting more serious about converting dissectors to the "new style".  I submitted a bunch of patches where it 
was obvious that the dissectors fell into the "give me everything" category.  My biggest worry is the comment made by 
Guy in bug 11134 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11134#c13), that some dissectors want to "accept" 
a tvb (packet) as their own, but don't actually parse any bytes (so it appears that they would "return 0" with the new 
style).  So the remaining ones I'm taking more slowly (with the attitude of unsure means leave as old style) and if 
anyone know of protocols that behave this way, feel free to convert them (or send me a note)

The case I keep coming across that I'm not sure how to deal with is dissectors that get a few bytes in (and have 
already created trees/items for a few fields), and then decide they aren't going to dissect anymore because of a "bad" 
field value (most commonly "version" or "length").  Should we apply a consistent rule for this?  Like if you're not 
going to dissect "versions" you don't support, check before making trees and just not bother with expert info saying 
"version isn't supported" while ceasing dissection.  Or dissect as "latest version" (or at least "a" version), but with 
the expert info applied that the version is unknown.  I'm not sure which scenario users would appreciate more, but I'd 
like to see it applied as consistently as possible. I believe my preference is for using expert info, but continuing 
dissection.
Are such rules more critical for popular protocols like Ethernet, IP and TCP/UDP where there are possibly "shared" 
values for a subdissector identifier?

Also, should we clean up a tree if a new-style dissector returns 0 (within the functions in epan/packet.c)?  I think 
the expert info would be harder to clean up, but I'm also not sure of the difficult of the trees either.

Opinions welcome, but I'd like to see the "new" style be the "only" style by the 2.2 release.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe