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
