Hi Pascal, > If you check the mailing list archive you will see that I also raised > this issue regarding filter names for protocols split across several > files. See http://www.wireshark.org/lists/wireshark-dev/201207/msg00258.html > for the mail exchange.
Yes, I've seen this (I replied in the same email thread :) > So far only Michael and myself have expressed our opinion on those > "meta" protocols split across several files. Personally I preferred > the previous filter scheme despite the warnings generated by the > checkfiltername.pl script. It would be good if other people were also > giving their feeling (as you did) so that we can decide once for all > whether the dissectors or the script must be changed for this use case > and try to stick to this decision in the future. As I said, I didn't take the decision lightly, I hesitated between both options (and actually you can even see the rest of a bad 'sed' in some of those where you find gmr1.rr._xxx ...). I the end I chose the one that made the most sense and confirmed with the ML ( http://www.wireshark.org/lists/wireshark-dev/201202/msg00033.html ) and IRC there was no objection. Anders Broman responsed that it looked reasonable and he's the one who merged them IIRC. > Note that the change was done in the development branch only and that > next stable release from this code base is due in a year so we still > have plenty of time to change things. That would be nice :P I don't know all the protocols where this happens but to me having gmr1_rr.xxx or gmr1_common.xxx makes it believe those are different protocols which they're not ... GMR-1 is the protocol and then you have the channel types like CCCH on which you can find messages that can contain elements from RR/CC/... And so having the hierarchy protocol (gmr1) / category of element (common / rr / cc / ...) makes sense to me. Those category are not arbitrary either, they're explicitly defined that way in the official specifications, I'm not making them up. If someone has a good argument _against_ this, I'd be interested to hear it. (And the fact the checkscript can't deal with it is not really a good argument ... at worse we could add meta-tags in the header of those files to define the prefix allowed to be used) Cheers, Sylvain ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
