<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">There would be a lot more to gain from moving in the direction of OpenTrac as a new direction than trying to do more with APRS. AX.75 supports the use of other protocols in band with APRS. We need to move on and use a protocol like OpenTrac to have extensibility and highly vertical customizations for unique applications.<div><br></div><div>Gregg</div><div>W5GGW<br><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On May 24, 2020, at 11:03 AM, Robert Bruninga <bruninga@usna.edu> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>As I am retiring next month, I do hope to eventually sit down and clean up the APRS1.1 and APRS1.2 portions of the spec and help remove any inaccuracies or conflicts. I welcome identifications of these things to look at.<br><br></div>Bob<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 23, 2020 at 9:42 PM Andrew Pavlin via aprssig <<a href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</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"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px"><div></div>
<div dir="ltr">Hello, Ian.</div><div dir="ltr"><br></div><div dir="ltr">I'm afraid you have a few misunderstandings, and a long uphill row to hoe to do what you're trying to do.</div><div dir="ltr"><br></div><div dir="ltr">1. APRS was not created by a central standards body, but by many people working independently. Although Bob Bruninga WB4APR is technically the final authority on anything in APRS, people don't always check with him (even though they should). And once some of these things get out there, they're out there forever. It's like trying to erase something from the Internet: impossible, because there are too many copies scattered around.</div><div dir="ltr"><br></div><div dir="ltr">2. Because of this, APRS has grown organically for several different purposes that share a common infrastructure, so there are several different ways to do things, optimized for different use cases. For example, Mic-E was originally optimized for a very short signal "burp" at the end of a voice transmission, so as to not extend the transmission significantly while still getting position data piggybacked on the voice transmission. But now, every single designed-for-APRS radio, including the Kenwoods and Yaesus, plus remote-operator devices like the Byonics MT-AIO, and many stand-alone TNCs all support this position format, either by default or as the only position format choice. Other use-cases can't use this format because they can't type the control codes into the packets, so they have to use an all-printable-ASCII format like the uncompressed position report. And a general-purpose APRS client like Xastir, APRSIS32, YAAC, APRSdroid, or <a href="http://aprs.fi" target="_blank">aprs.fi</a> has to support all of them, because it doesn't know who or what other stations the user is going to be working with.</div><div dir="ltr"><br></div><div dir="ltr">3. Amateur radio infrastructure changes _very_ slowly, because changes come literally out of the wallets of individual radio operators. If something works, they're not going to replace it just because someone else says the change is a good idea, but only because they personally get a benefit from the time and money spent. For example, Bob proposed the New-N paradigm to fix digipeating issues in 2004. That should only be a software change, so existing hardware could do it with a simple firmware change. Yet there are _still_ not only leaf-node stations, but digipeaters doing it the old way (and, alas, non-updated webpages still telling them to do that). Backwards compatibility is a very important issue. UI-View is a dead program; its author has been a Silent Key since 2004, and the program cannot be upgraded. Yet people are still using it. Scott Miller N1VG tried to come up with a next-generation APRS, called OpenTRAC, making the message formats more consistent so support of multiple varying use cases would be easier, and systems who didn't care about a particular use case could ignore it with impunity, and leaving behind some of the kludges from no-longer-necessary restrictions of obsolete hardware. OpenTRAC was (and still is) a very nice clean specification, but it sank like a lead balloon because it wasn't backwards compatible with the existing APRS infrastructure (even though it could co-exist with APRS) and OpenTRAC didn't add enough value over the existing support of the outstanding hodge-podge in APRS for very many people to make the effort to support it.</div><div dir="ltr"><br></div><div dir="ltr">So you can't just say "message format XXX is no longer supported", because people are still using that format, and are going to keep using that format. Even Bob WB4APR can't stop existing use-cases. Some message formats are declared deprecated (ex.: RELAY and WIDE digipeating aliases, Maidenhead format position reports), and new implementations should not transmit them, but, because of existing users, support for receiving them can't go away. Different variations of position reporting exist for different use cases. For example, compressed mode positions have higher position precision than human-readable ASCII position reports (even more than Mic-E can do), but not all implementations can understand them. Is that a reason to discard them? Mic-E is unreadable by human beings examining binary packets, but extremely compact, saving bandwidth and air time as long as you have the minimal <span>receiving-end</span> computer power needed to decode it. The !DAO! hack was introduced to increase precision while being backwards-compatible, but it's less efficient (more bytes per packet), and just as human-unreadable as Mic-E and compressed-mode text.<br></div><div dir="ltr"><br></div><div dir="ltr"> You quoted Postel's Law, so I'm assuming you're familiar with some of the rules that manage the Internet. Remember the rest of Postel's Law: <span>"Be conservative in what you send, be liberal in what you accept".</span> Jon Postel _knew_ he was herding cats (to use the simile for managing computer programmers). The Internet's protocol stack allowed developers to do different things in different ways compatibly, so (for example) you don't have to use HTTP for something it is manifestly unsuitable for (such as SSH terminal sessions). Alas, APRS didn't have a tall enough layered stack to separate different use cases cleanly, because of the primitive hardware it was originally developed on, which often required an actual human being to be the data interpreter rather than a computer.<br></div><div dir="ltr"><br></div><div dir="ltr">Creating an APRS 1.2 complete protocol specification is a worthy task, bringing the APRS 1.0.2 spec up-to-date with the 1.1 and 1.2 changes. But you can't just throw out sub-protocols that are still being used (bad as they may be), or mandate new special-use-case features at users who don't need them and will never implement them. You could consider APRS 1.0.2 as the common baseline (and even parts of that are optional for certain use cases, such as an originating station's free choice of which position format to use), and APRS 1.1 and 1.2 as collections of extensions, most of which are optional, but should be implemented as specified if they are done at all. Of all of APRS 1.1 and 1.2, only the New-N paradigm is really required (because it affects every user); nearly everything else is special use-cases (for an Internet equivalence, compare the use cases of FTP, SMTP, HTTP, and Telnet, all radically different use cases that work over common TCP and IP lower-level protocols).</div><div dir="ltr"><br></div><div dir="ltr"> The tocall specification and 1.2 symbol overlay specification are living documents of common conventions used to identify station and object types. Not knowing a new one won't kill a receiving station, because it doesn't change the way the receiving station handles the packets.</div><div dir="ltr"><br></div><div dir="ltr">So whether you want to write one new specification, or a core specification and a sheaf of extension specifications (as the Internet protocols are done), up to you. The latter makes more sense from an aesthetics point of view, but makes it more likely something will be missed (unless you have a master document equivalent to STD 3 on the Internet).<br></div><div dir="ltr"><br></div><div dir="ltr">How can I stand on my soapbox and proclaim all this? I've been a professional software and network engineer for over 40 years (!), and I'm the author of YAAC ("Yet Another APRS Client"), which I began implementing in 2011, long after APRS started; YAAC didn't go public until 2012 (which is still nearly 9 years of APRS experience since the first line of code, but a mere fraction of the 26+ years the current form of APRS has been around in its various permutations). I tried to write my implementation from scratch (as you are apparently trying to do) as an exercise for the student, so I would know how APRS really works by hands-on experience. But I also tried to follow the APRS specs and Postel's Law rigorously, in full conformance with Bob Bruninga's expectations and intentions, even when they all were contradictory, and so I was able to support anything unexpected the network threw at me. Yes, I had to make a lot of fixes over the years, but many of those were due to my lack of understanding as I expanded YAAC to include more use cases, not necessarily a protocol violation on a sending station's part. On the other hand, there are still a lot of errors on the part of sending stations due to their protocol violations (especially on the stations where the packets are created by hand [by an operator lacking understanding or typo-free data entry] through editing the BEACON command of a TNC), and we just have to deal with it (Postel's Law again) and gently steer those users to the correct way, without encouraging them to continue in error by actively supporting their error.</div><div dir="ltr"><br></div><div dir="ltr">Note that your idea of updating the spec is great for that gentle steering, as long as it accounts for the issues mentioned above (and is cleared by the Father of APRS, Bob Bruninga). Doing otherwise would be like hacking the Linux kernel against Linus Torvalds' directions.<br></div><div dir="ltr"><br></div><div dir="ltr">Note that there are already a large number of programs available for FreeBSD that do APRS, so you don't need to re-invent the triangular wheel for HamBSD. I see that you already have written your own applications to try to replace the connected-mode-oriented AX.25 stack available for Unix/Linux/FreeBSD with a stack oriented towards APRS. Will that obstruct doing other protocols (such as the Fldigi suite or Winlink) or other interfaces (such as DireWolf over sound cards instead of hardware TNCs, or YAAC or Xastir's UIs)?<br></div><div dir="ltr"><br></div><div dir="ltr">I am preparing to review your entities.txt document, which I see you carefully structured in standard Internet RFC format. Are you interested in review comments?</div><div dir="ltr"><br></div><div dir="ltr">Andrew, KA2DDO</div><div dir="ltr"><br></div><div><br></div>
</div><div id="gmail-m_4163243356476951126ydp8e7a9d58yahoo_quoted_1204359974">
<div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
<div>
On Saturday, May 23, 2020, 3:41:13 PM EDT, Iain R. Learmonth <<a href="mailto:irl@hambsd.org" target="_blank">irl@hambsd.org</a>> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Hi,<br></div><div dir="ltr"><br></div><div dir="ltr">In attempting to write code that produces position reports for stations,<br></div><div dir="ltr">objects, and items I have ended up with some notes. They are far from<br></div><div dir="ltr">being complete but I'm already starting to find some contradictions and<br></div><div dir="ltr">perhaps some things that need changing now time has moved on.<br></div><div dir="ltr"><br></div><div dir="ltr">In particular, I think there needs to be some application of Postel's<br></div><div dir="ltr">Law to the specs. We should determine what the correct thing is to send<br></div><div dir="ltr">now, and what things you might be expected to receive. We should also<br></div><div dir="ltr">consider what the correct thing to send might be in the future, and<br></div><div dir="ltr">prepare implementations for that change.<br></div><div dir="ltr"><br></div><div dir="ltr">Items are not recommended in APRS 1.1, however this appears to be a<br></div><div dir="ltr">mistake according to an email from Bob that recommends only against the<br></div><div dir="ltr">compressed format for items, which I guess also applies to objects? So<br></div><div dir="ltr">it's not really clear if we should be avoiding compressed formats<br></div><div dir="ltr">everywhere.<br></div><div dir="ltr"><br></div><div dir="ltr">There is also the Mic-E format, which I haven't looked at at all yet. I<br></div><div dir="ltr">wonder to what extent that can be treated as an extension to the APRS<br></div><div dir="ltr">specification rather than a core part of it. Would it be recommended to<br></div><div dir="ltr">implement Mic-E position reports over an uncompressed/compressed<br></div><div dir="ltr">position report?<br></div><div dir="ltr"><br></div><div dir="ltr">Finally, has anyone worked on combining the spec addendums with the spec<br></div><div dir="ltr">to form a coherent document? The editing process for that would surely<br></div><div dir="ltr">work out some of the bugs. I might volunteer to do this if it has not<br></div><div dir="ltr">been done and there is support for such a thing.<br></div><div dir="ltr"><br></div><div dir="ltr">My notes so far are attached. The references section at the end contains<br></div><div dir="ltr">all the documents that were drawn on in order to put together the notes<br></div><div dir="ltr">so far, but as you'll see there are still lots of holes.<br></div><div dir="ltr"><br></div><div dir="ltr">Thanks,<br></div><div dir="ltr">Iain.<br></div>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@lists.tapr.org" rel="nofollow" target="_blank">aprssig@lists.tapr.org</a><br><a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="nofollow" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br></div>
</div>
</div></div>_______________________________________________<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></div>
<span>_______________________________________________</span><br><span>aprssig mailing list</span><br><span>aprssig@lists.tapr.org</span><br><span>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</span><br></div></blockquote></div></body></html>