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