[aprssig] APRS tocalls.txt - practical steps

[Scott Howard]

On Fri, Feb 11, 2022 at 3:36 PM Heikki Hannikainen <hessu at hes.iki.fi> wrote:
>
> On Fri, 11 Feb 2022, Steve Dimse wrote:
>
> > I have no problem with you taking over allocating the IDs for now, if
> > you agree to yield in the future should a protocol group emerge.
>
> Sure, like I wrote already: If an APRS standards committee / organisation
> develops later on, I'll be happy to pass on the responsibilty of
> maintaining the list to such a group. This is a fairly boring task that
> I'm more than happy to let someone else do. Which is one reason why I'd
> prefer to invite a couple of other people (preferably people with some
> prior experience with git and github) to help out and have commit
> privileges so that allocations could be made even if I'm away for a few
> weeks. Which is one reason why I'd like to do it on github.

In my opinion, that sounds like a good starting point. To start
assembling volunteers, I think it might be helpful to think of the
maintenance tasks that are required, and see who is volunteering. To
do that, I think we can categorize the different things APRS is along
the entire OSI stack to help clearly define what is "APRS." Governance
might mean different things for each layer, and the same people don't
need to manage or even be involved with all of it. And some things
might not even need maintenance.

1) Physical Layer: APRS as carried over radio waves. defining what
frequencies and encoding people should set up their digipeaters to
(right now, it's VHF AFSK). There's some HF, too. This includes
coordinating regional digipeaters, if necessary.
2) Data Link Layer: What is an APRS frame? Right now, this is the APRS
protocol spec. Basically it's just simple AX.25 UI frames. There is
also some media access control (CSMA), but that's not formally
included in the specification.
3) Network Layer: How does APRS know where to send stuff? While AX.25
is pretty much only Layer 2, APRS leaks a little bit into layer 3 by
using WIDEn-N, altnets, etc.
4-5) not really in APRS (I could be wrong)
6) Presentation Layer: All the possible data payloads (APRS data
types), Base-91, Mic-E. Probably where tocall is too
7) Application Layer: I believe this is in the domain of the end-user
facing software tools as well as how people use it (e.g., voice alert)


The key tasks, IMO, in order of layer:
Physical Layer: I don't think this is something that can be a top-down
thing, beyond suggestions. Those participating in the network set it
up as their region permits. This might be some regional coordination
just like people do with repeaters.
Data Link Layer: Maintain some document that just maintains what APRS
uses for a data link. Right now it's AX.25 UI frames, with a suggested
CSMA method. Updating this is a very rare thing unless there's a major
evolution in APRS (in which case, it might not even be APRS anymore)
Network Layer: Maintain a document that describes the WIDEn-N protocol
and usage of altnets. Updating this is probably going to be very rare.
Presentation Layer: A document that describes the APRS data types
(basically the current APRS spec), and the meaning of the tocalls,
symbol tables, etc. Maintaining this is what will take some work and
will probably need a team. The team probably should consist of the
major hardware and software developers.
Application Layer: something else that shouldn't be top down.

I see 2 documents so that one can be updated without reissuing both.
1) A strong protocol specification for the data link layer and the
network layer (WIDEn-N). This rarely changes (see how AX.25 rarely
changes).
2) A "living document" or database of data types, tocalls, symbols.
This also should allow for experimental user defined ones as well
(that could possibly become "official" ones)

One team could manage both of those. I see the goal of APRS
maintenance as enabling people to experiment on their own in the
application and physical layers, and give a strong specification for
the middle part. Let APRS protocol (and network) be the thing to
enable innovations.
-Scott