<div dir="ltr">I'm interested in the notion of keeping the "standard" layer-based. Considering for instance there is nothing that really defines APRS-IS as a data link layer, even though that's what it ends up being. All we have is something that serves as a reference implementation (in Java, if I'm not mistaken) and some derivative server daemons and services written in other languages.<div><br></div><div>As for the network, the New-N paradigm and how altnets should operate sounds appropriate, though there will have to be some amount of "retroactive documentation" if that's even possible on how APRS used to work (Bob had a LOT of this on his site).</div><div><br></div><div>Application layer is where all the content will be (and is primarily the APRS101.PDF if I'm not mistaken). Creating tools and registries for TOCALL, symbols, additional data types would be helpful to manage in separate appendices, but realistically they would be stored and versioned as their own things. I envision having reference designs in SVG format for symbols that can be used as-is or rasterized for use (color or monochrome) in device updates/firmware, etc. What a world that would be...</div><div><br></div><div>Or even having a place where new symbols could be proposed and vetted and approved, issued as a rev on the specification, and then promoted outward to manufacturers to issue firmware updates to their devices. Wouldn't that be something: to see manufacturers able to support new functionality in APRS as a result of new ideas and features.</div><div><br></div><div>I'm getting myself all worked up here, it's exciting stuff!</div><div><br></div><div>Anyhow, looking forward to seeing this coalesce (coagulate?) into something that really reflects the community.</div><div><br></div><div>--R<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><i>--</i></div><i><b>Randy AA6RH</b></i><div><i><a href="mailto:aa6rh@socorad.io" target="_blank">aa6rh@socorad.io</a></i></div><div><i>Grid Square: CM88pl</i></div><div><i><a href="https://www.qrz.com/db/aa6rh" target="_blank">QRZ Profile</a><br></i></div><div><i>Sonoma County DMR: <a href="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" target="_blank">BrandMeister 31707</a></i></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 11, 2022 at 3:32 PM Scott Howard <<a href="mailto:showard@nd.edu">showard@nd.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Feb 11, 2022 at 3:36 PM Heikki Hannikainen <<a href="mailto:hessu@hes.iki.fi" target="_blank">hessu@hes.iki.fi</a>> wrote:<br>
><br>
> On Fri, 11 Feb 2022, Steve Dimse wrote:<br>
><br>
> > I have no problem with you taking over allocating the IDs for now, if<br>
> > you agree to yield in the future should a protocol group emerge.<br>
><br>
> Sure, like I wrote already: If an APRS standards committee / organisation<br>
> develops later on, I'll be happy to pass on the responsibilty of<br>
> maintaining the list to such a group. This is a fairly boring task that<br>
> I'm more than happy to let someone else do. Which is one reason why I'd<br>
> prefer to invite a couple of other people (preferably people with some<br>
> prior experience with git and github) to help out and have commit<br>
> privileges so that allocations could be made even if I'm away for a few<br>
> weeks. Which is one reason why I'd like to do it on github.<br>
<br>
In my opinion, that sounds like a good starting point. To start<br>
assembling volunteers, I think it might be helpful to think of the<br>
maintenance tasks that are required, and see who is volunteering. To<br>
do that, I think we can categorize the different things APRS is along<br>
the entire OSI stack to help clearly define what is "APRS." Governance<br>
might mean different things for each layer, and the same people don't<br>
need to manage or even be involved with all of it. And some things<br>
might not even need maintenance.<br>
<br>
1) Physical Layer: APRS as carried over radio waves. defining what<br>
frequencies and encoding people should set up their digipeaters to<br>
(right now, it's VHF AFSK). There's some HF, too. This includes<br>
coordinating regional digipeaters, if necessary.<br>
2) Data Link Layer: What is an APRS frame? Right now, this is the APRS<br>
protocol spec. Basically it's just simple AX.25 UI frames. There is<br>
also some media access control (CSMA), but that's not formally<br>
included in the specification.<br>
3) Network Layer: How does APRS know where to send stuff? While AX.25<br>
is pretty much only Layer 2, APRS leaks a little bit into layer 3 by<br>
using WIDEn-N, altnets, etc.<br>
4-5) not really in APRS (I could be wrong)<br>
6) Presentation Layer: All the possible data payloads (APRS data<br>
types), Base-91, Mic-E. Probably where tocall is too<br>
7) Application Layer: I believe this is in the domain of the end-user<br>
facing software tools as well as how people use it (e.g., voice alert)<br>
<br>
<br>
The key tasks, IMO, in order of layer:<br>
Physical Layer: I don't think this is something that can be a top-down<br>
thing, beyond suggestions. Those participating in the network set it<br>
up as their region permits. This might be some regional coordination<br>
just like people do with repeaters.<br>
Data Link Layer: Maintain some document that just maintains what APRS<br>
uses for a data link. Right now it's AX.25 UI frames, with a suggested<br>
CSMA method. Updating this is a very rare thing unless there's a major<br>
evolution in APRS (in which case, it might not even be APRS anymore)<br>
Network Layer: Maintain a document that describes the WIDEn-N protocol<br>
and usage of altnets. Updating this is probably going to be very rare.<br>
Presentation Layer: A document that describes the APRS data types<br>
(basically the current APRS spec), and the meaning of the tocalls,<br>
symbol tables, etc. Maintaining this is what will take some work and<br>
will probably need a team. The team probably should consist of the<br>
major hardware and software developers.<br>
Application Layer: something else that shouldn't be top down.<br>
<br>
I see 2 documents so that one can be updated without reissuing both.<br>
1) A strong protocol specification for the data link layer and the<br>
network layer (WIDEn-N). This rarely changes (see how AX.25 rarely<br>
changes).<br>
2) A "living document" or database of data types, tocalls, symbols.<br>
This also should allow for experimental user defined ones as well<br>
(that could possibly become "official" ones)<br>
<br>
One team could manage both of those. I see the goal of APRS<br>
maintenance as enabling people to experiment on their own in the<br>
application and physical layers, and give a strong specification for<br>
the middle part. Let APRS protocol (and network) be the thing to<br>
enable innovations.<br>
-Scott<br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div>