[aprssig] APRS tocalls.txt - practical steps

Fri Feb 11 12:41:01 EST 2022

>
> 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.
>

I agree wholeheartedly that telemetry is an area where APRS as a protocol
could do much better.

I do have concerns about registries. This starts down the slippery slope of
gatekeeping, which I know exists is the realm of repeater coordinators
already. I understand the need for repeater coordinators, and it may be
useful in *some* metropolitan areas to need coordination in order to have
digis and igates play nicely together (looking at you, SF Bay Area). I
would suggest providing a framework to those geographies so that they can
be more successful in coordinating stations, while not limiting the
usefulness of the overall APRS network by stifling novel ad-hoc stations
for things like public service events, actual emergency incidents, etc.

But yeah, telemetry is relatively unplowed soil for APRS.

--R
*--*
*Randy AA6RH*
*aa6rh at socorad.io <aa6rh at socorad.io>*
*Grid Square: CM88pl*

*QRZ Profile <https://www.qrz.com/db/aa6rh>*
*Sonoma County DMR: BrandMeister 31707
<https://brandmeister.network/?page=lh&jsonquery=%7B%22condition%22%3A%22AND%22%2C%22rules%22%3A%5B%7B%22id%22%3A%22DestinationID%22%2C%22field%22%3A%22DestinationID%22%2C%22type%22%3A%22integer%22%2C%22input%22%3A%22text%22%2C%22operator%22%3A%22equal%22%2C%22value%22%3A%2231707%22%7D%5D%7D>*

On Fri, Feb 11, 2022 at 9:13 AM 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/20220211/47fc38f7/attachment.html>