[aprssig] APRS tocalls.txt - practical steps

Fri Feb 11 19:29:38 EST 2022

 Since I sort of started this whole mess by digging out an old email thread from when Bob first saw mortality staring him in the face and started thinking about a transition of APRS leadership.....
I am willing to contribute what I can to the process (some labor, red-tape slicing, etc.). I like the suggestion of a 3-month goal. That gives us the opportunity to report our progress, say, at Dayton Hamvention this May (assuming Hamvention happens and we still have the forum timeslot reserved for Bob's State of APRS presentation), and the deadline pressure to actually _do_ something. The biggest hassle is managing protocol spec changes. The original spec is version 1.0.1, and we've had versions 1.1 and 1.2 basically appear as giant disorganized errata sheets, mostly of new optional features, rather than non-backwards-compatible changes in the base protocol. And I'm not sure if we have anyone as tough as the editor of the 1.0.1 specification to handle organizing, publishing, and getting reviews of a 1.2 consolidated document. So we need a process (that isn't excessively gatekeeper-ish) to review new ideas and make sure they don't break APRS As She Is Written.

All the big standards bodies have a process for submitting new documents and document revisions, where the Internet Engineering Task Force (IETF) is one of the well-known ones. The process always involves peer review and testing of the proposed Experimental-state change before it is voted on for rolling into the Proposed Standard or Draft Standard state. Someone once started an Amateur Radio Engineering Task Force (ARETF) ARETF; I think I'm the only person who ever submitted a proposed standard document to them (which, interestingly enough, was a backwards-compatible optional feature extension for APRS [which had gone by Bob, but was more formalized in the proposed standard document]). Not sure if anything is still happening there; the dates are rather old on their web pages, but they are still up.

| 
| 
|  | 
ARETF

Amateur Radio Engineering Task Force
 |

 |

 |

Can TAPR or AMSAT give us some advice on how to set up a formal and legal structure for this sort of body? They've been doing it for 30-some-odd years (at least)? Any lawyers familiar with the effective process for organizing a non-profit like this? I think we'll need some kind of structure, because it costs money to run websites and the like.
Andrew, KA2DDOauthor of YAAC ("Yet Another APRS Client"), a Free and Open-Source Software

    On Friday, February 11, 2022, 12:13:34 PM EST, Bob Poortinga <aprssig at k9sql.us> wrote:  

 Since Steve asked for comments, here is my 2 cents.
I think it is wonderful that Hessu has volunteered to take on this task.  I fully support him doing this (with Steve's conditions). This is something that needs to be done without introducing needless delay. I also fully support the move to Github which is something that should have done years ago. Any other APRS metadata which requires updating and maintenance should also be moved to Github.
Hessu has been doing a lot of the heavy lifting in the area of modernizing APRS. This is a protocol that is almost 30 years old and badly needs to be updated and streamlined if it is to remain viable. That includes removing some of the kludges introduced into the protocol by Bob for devices and software that no longer exist and features that are never used. Bob had great ideas and imagination, but implemention was sometimes a hack.
One area that I see being important to the future of APRS is telemetry which should be expanded and improved. Another thing that I would to see is a registry for digipeaters (and possibly igates) that allow identification and operator contact for stations with issues such as the well known "delayed packet" problem. At some point, coordination of digipeaters may also be necessary as well as local policy digipeating.

Bob was a visionary, but also opinionated and stubborn at times which sometimes worked against him. Being of Dutch (Fries) ancestry myself, the saying " You can tell a Dutchman, but you can't tell him much" is often ascribed to us. RIP, Bob.
73,Bob Poortinga W9IZ

On Fri, Feb 11, 2022, 11:02 AM Steve Dimse <steve at dimse.com> 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.

I am unconvinced there is a need for any new infrastructure in the short term, I can update the aprs.org site with any changes you send to me. People already know to look there.

If you do choose to proceed with a github site please publicly commit now to either closing it or turning it over to a group that takes on maintaining the protocol and aprs.org site, as well as relinquishing responsibility for allocating new IDs, should such an APRS protocol group emerge. We do not need the first thing that happens after Bob's death to be an irrevocable split of the allocation of new IDs from the rest of the protocol, or worse having two competing registrars.

Without a public commitment to yield to an APRS protocol group should one emerge, then I would strongly object to anyone taking over any part of the protocol in the near term. 

If, in say three months, there is no such group, then consider my objection removed, and you (and everyone else) are free to do anything you want on IDs or any other part of the protocol. I have had several private conversations with people who want to put a group together, I am encouraging them to go public but none feel ready yet and are continuing to work behind the scenes. I hope I'm wrong, I have doubts there will be a group, but I really believe we should give it a chance. Three months is not a long time to wait.

How do other APRS users feel? We really need to make this more of a discussion. One of the concerns the most promising candidate expressed privately is the apathy on the list so far. There are hundreds of people on this list, and only a few have said anything. So this is the first chance for public comment about a specific question. If you have an interest in APRS speak now or forever share the blame (or credit) for what happens!

1. Do you think an APRS protocol group or organization of some sort is a good idea?

2. Should Hessu start new infrastructure to handle IDs now?

3. If not is three months an appropriate length of time to wait to see if a group can form? Suggest another if you wish.

Steve K4HG

> On Feb 11, 2022, at 10:23 AM, Heikki Hannikainen <hessu at hes.iki.fi> wrote:
> 
> 
> Hello,
> 
> 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):
> 
> https://github.com/hessu/aprs-deviceid/blob/master/tocalls.yaml
> 
> 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:
> 
> https://github.com/hessu/aprs-deviceid/tree/master/generated
> 
> 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:
> 
> https://github.com/hessu/aprs-deviceid/commits/master
> 
> 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).
> 
> https://github.com/hessu/aprs-deviceid/commit/ac6c0436f85579b7b8e6ef345f41d771a2621213
> 
> 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.
> 
> https://github.com/hessu/aprs-deviceid/issues?q=is%3Aissue+is%3Aclosed
> 
>  - Hessu, OH7LZB / AF5QT, aprs.fi
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220212/0fcd9efc/attachment-0001.html>