[aprssig] APRS protocol replacement ideas: protobuf

[Scott Howard]

On Sat, Feb 12, 2022 at 3:04 AM Heikki Hannikainen <hessu at hes.iki.fi> wrote:
>
> On Fri, 11 Feb 2022, Weston Bustraan wrote:
>
> > I can say that it was not easy to navigate the many exceptions and and
> > oddities in the APRS 1.0.1 spec when implementing a parser, and OpenTRAC
> > seems much more consistent, but the OpenTRAC spec does not seem to be
> > fully complete. For example, I would expect that any new protocol that
> > would supplant APRS would be supporting a UTF-8 character set instead of
> > just ASCII.
>
> Yes! Implementing all variations and details of APRS is quite difficult
> indeed, as there are so many completely different position formats, and
> various quirks in which order extension fields should be decoded in, and
> the specifications do not detail all of those. It is unnecessarily complex
> and an awful lot of work.

protobuffs sounds great, and I think both you and Weston hit on one of
the key points to the future of APRS. I think that whatever protocols
come up next, the priority should be on extensibility so that things
like protobuffs could be used. I think getting away from ASCII towards
binary buffers (UTF-8) would be a way to achieve what Mic-E does
without leaking between protocol layers (allow for more efficient
payloads without hacking DEST), but that would need some kind of
extensible spec. For "official" data types, the schema is published
and well known (maintained in some document somewhere). For
new/experimental extensions, maybe have one packet send out the schema
and the second the payload (kind of like telemetry does). It can use
protobuffs or just our own protobuffs-lite.

Since much of the new applications of APRS is in embedded systems,
computer modems, and web applications, new protocols can be
implemented and adopted faster than they can be approved by some
centralized body (e.g., if some arduino library compatible with
aprs.fi and direwolf implements something, it'll go live immediately).
I think that would be amazing, and the type of innovation we want to
see. Therefore, some standard as to how that can be done might be
better than trying to formalize every use case or application.

(Of course, APRS has to support the legacy applications and protocols.)