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