Thank you, Neels and Shinjo, for your insights.
What I was thinking is defining a new data structure for each payload type and optionally extend them in the future using TLV entries. See my proposal for the type-specific data structure.
@Shinjo, I did not know about your existing proposal. I understand the idea about type specific headers, but I think it may lead to problems and increased compatibility issues in the future, as more types are added. I would suggest to use TLV exclusively.
In addition, I will going to present a talk in this OsmoDevCon, and I am currently planning to finalize the proposal before the conference.
That is good news, good luck for your proposal.
---
@Neels, do not say you are bikeshedding, because your comments are not trivial at all... :D
Just to understand the aim: we can of course fix the wireshark dissector to handle the version properly. The idea to keep v3 backwards compatible is only about making older wireshark installations "magically" compatible with the new gsmtap version?
Yes, it is only about that. For me it is not a strong requirement, just a nice-to-have, as you say.
What makes v3 to v2 compatibility such an important requirement?
It can be a design constraint, or not. In my initial message I tried to lay down the most safe and backward compatibile proposal possible.
(If someone back in 2012 had fixed wireshark to handle the version number properly, then no-one would even mention it today. Seems silly to design a protocol around such a short-lived peculiarity of one specific program.)
I can send a merge request to Wireshark team to address this. The sooner we add this version check the better.
things become a lot easier when there is no variance in the sizes of the length field. If the aim of this is to save one byte of payload, I find this quite anachronistic.
From the notes of the 2012 talk, I understood that someone would be happy with this level of optimization. Having a single format (T16L16V) will of course be the most simple and efficient (CPU wise) solution. Also, 12 years have passed.
It's essentially the same as you suggest, but it unloads the protocol definition from having to coordinate specific vendors' tag ranges.
I agree, it is a nice change of perspective.
The final part of your email about extensions and vendor specific tags is really interesting, but I do not have enough experience to give you a useful feedback. I wonder if we can copy this mechanism from an existing protocol definition.
Thanks,
Mauro