[aprssig] APRS tocalls.txt - practical steps

Heikki Hannikainen hessu at hes.iki.fi
Fri Feb 11 10:23:30 EST 2022


Sad news indeed, and I guess some practical things need to be sorted out 
soon. Here's one: tocalls and Mic-E identifiers for new apps and devices.

I've been meaning to propose publicly that the APRS unique identifiers 
allocation (device identifiers / tocalls / mic-e IDs, and additional 
secondary symbol table extensions) tables would be maintained on Github, 
where a team of few people could maintain the master list, instead of 
having just one person do it. The machine-readable aprs-deviceid list [1], 
which I've been maintaining since 2013, which tracks tocalls.txt and is 
currently in sync with it, could serve as the new primary list for 
tocalls/mic-e. I'd just move it to a github organization and add a couple 
of additional maintainers there.

Bob seemed happy with me maintaining the list (we discussed this a few 
times over email during the course of a couple years, and he said last 
March in an email about an additional symbol identifier that "Lets see if 
Hessu agrees. He is taking over assignments."), but I'd rather have a 
couple of others with permission to update, and a documented criteria for 
good additions, so that it wouldn't depend on my availability.

The benefits of the git approach are:

* There is a clear record of all changes and change requests
* The machine-readable database can be used directly in APRS applications 
to identify other apps based on packet contents, and the database can be 
updated automatically by just downloading the file in the app or during a 
build process
* Github supports multiple maintainers nicely, as it is a distributed 
development platform
* Git repositories, with complete revision history, can be easily backed 
up (by anyone, including yourself, from this public github repository) and 
moved from Github to some other place if necessary later on.

Until now I have only added devices there only after they appeared in 
Bob's text file, and if someone tried requesting an entry directly to 
aprs-deviceid, I bounced them to Bob first.  The first request ticket to 
add new allocations already came in yesterday, but I've put it on hold for 
a bit.

I can volunteer to set the github organisation up. 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. I've licensed the 
files under the CC BY-SA 2.0 open source license, so technically it 
wouldn't need my permission anyway, if someone wanted to fork the 
database, and people would rather use the forked list instead. I chose the 
license so that other APRS developers could use the files freely in their 
applications, but it allows forks just as well.

I propose that this shall be discussed over the weekend, and if there is 
some sort of consensus that I should do this, I'll start adding new 
allocations and setting up the other things some time next week.  If there 
isn't consensus and someone else would rather maintain tocalls.txt, then 
I'll refrain from allocating new identifiers for now.

[1] https://github.com/hessu/aprs-deviceid

The master list is edited in YAML (a machine-readable format itself):


Which is then converted to JSON and XML with a script, and developers using this
data in their applications can then choose to read in one of the three formats,
depending on their preferences:


In addition to these I'd write a script to automatically publish a pretty 
(well, at least less ugly) HTML table with the current allocations for 
humans to browse, updated every time the master list is changed.

Changes are archived, like git does, and you can see some 3rd-party
contributions coming in as well already in the past:


All the changes and revisions are archived, so everyone can see what 
exactly was changed, and how. This is how most open source software is 
maintained these days (and a lot of closed source, as well).


People have mostly submitted update requests as Github Issue tickets, and 
occasionally over direct email. Tickets are nice as there's a public track 
of change requests, and their resolutions.


   - Hessu, OH7LZB / AF5QT, aprs.fi

More information about the aprssig mailing list