[aprssig] APRS tocalls.txt - practical steps

Fri Feb 11 11:16:52 EST 2022

Steve,
	I like this approach. Three months may be a little short for time to
have some group up and running but if there is a commitment in that time
frame that sounds good. It is good to set a deadline, else nobody will work
towards a conclusion. I have learned that in the commercial world.
Remembering that a goal is reasonable if it has a 50% or better chance of
being achieved, then it's a good goal. If you don't start something nothing
will get done. I have a lot on my plate now but I would volunteer to be in
this group. I probably don't have enough time to be a leader in it at this
point. It is worthy enough a cause that I will participate. I am not a
programmer or serious hardware builder but I have been around APRS since it
began. I can help organize and establish project goals and timelines etc.

Brian N2KGC

-----Original Message-----
From: aprssig [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Steve
Dimse
Sent: Friday, February 11, 2022 11:00 AM
To: aprssig
Subject: Re: [aprssig] APRS tocalls.txt - practical steps

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/ac6c0436f85579b7b8e6ef345f41d7
71a2621213
> 
> 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