[aprssig] aprssig Digest, Vol 191, Issue 22

[Paul Sadowski]

I'd love to help but I'm not an author...

But, having been an infrequent participant in UI Packet telemetry since 1996 and playing with DOS APRS since 1995 and MacAPRS since 1996 ... I do though have some of the old guy perspective.... and have had a contribution or two...  particularly the packet storm flooding discoveries in 1997-1998.

Does anyone else remember when the only positions that were expected by some major software were only in the area that consists of the intersection set of  Northern Hemisphere and Western Hemisphere...  a time when it seems one major author thought only US, Canada, and Mexico were thought to exist ;)

How about the big APRS Working Group meeting where only a few authors could or were allowed to attend?  

How about the on-line Battles about internet role within APRS... I learned a LOT from that one...  it when on for a few years.

Scott Miller and OpenTrac was probably ahead of its time...  maybe now is the time???  Probably it even needs to be updated.

How Many folks have read the Pulitzer Prize book "The Soul of a New Machine" (40 years old)... the Prologue I strongly relate to...  my point about that book...  the bag on the side of the machine...  thats what APRS has become I fear...

BIG KUDOs to ANDREW, Ian, Nick and Greg and many others recently trying to wade through what the APRS bag has become.  The compromises of the past are not always necessarily required of the future...  otherwise bleeding a vein might still be an accepted medical practice ;). Bob being "final authority"...  thats interesting and possibly telling how we arrived here....

I wish I was worth a hoot at software writing... it should be no surprise I think AIS and ADSB should be looked at as we consider options for the future ; BTW they too have some ugly parts).

old guy edging back and putting on his flame armor... 

AH6LS

Sent from my iPhone - my apologies for autocorrection and thumb typing mistakes

> Today's Topics:
> 
>  1. Re: What is a position report? (Robert Bruninga)
>  2. Re: [TinyTrak] How to Contribute? (LA Basin digipeating)
>     (Robert Bruninga)
>  3. (no subject) (luis ramos abad)
>  4. Re: What is a position report? (Gregg Wonderly)
>  5. Re: What is a position report? (Iain R. Learmonth)
>  6. Re: What is a position report? (Iain R. Learmonth)
>  7. Re: What is a position report? 

> From: Robert Bruninga <bruninga at usna.edu>
> 
> 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.
> 
> Bob
> 
> 
>> Andrew Pavlin via aprssig <
>> wrote:
>> Hello, Ian.
>> I'm afraid you have a few misunderstandings, and a long uphill row to hoe
>> to do what you're trying to do.
>> 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.
>> 2. Because of this, APRS has grown organically for several different
>> purposes that share a common infrastructure,
>> 3. Amateur radio infrastructure changes _very_ slowly, because changes
>> come literally out of the wallets of individual radio operators.
>> Andrew, KA2DDO
>> On Saturday, May 23, 2020, 3:41:13 PM EDT, Iain R. Learmonth <
>> irl at hambsd.org> wrote:
>> Hi,
>> In attempting to write code that produces position reports for stations,
>> objects, and items I have ended up with some notes. They are far from
>> being complete but I'm already starting to find some contradictions and
>> perhaps some things that need changing now time has moved on.
>> In particular, I think there needs to be some application of Postel's
>> Law to the specs. We should determine what the correct thing is to send
>> now, and what things you might be expected to receive. We should also
>> consider what the correct thing to send might be in the future, and
>> prepare implementations for that change.
>> Items are not recommended in APRS 1.1, however this appears to be a
>> mistake according to an email from Bob that recommends only against the
>> compressed format for items, which I guess also applies to objects? So
>> it's not really clear if we should be avoiding compressed formats
>> everywhere.
>> There is also the Mic-E format, which I haven't looked at at all yet. I
>> wonder to what extent that can be treated as an extension to the APRS
>> specification rather than a core part of it. Would it be recommended to
>> implement Mic-E position reports over an uncompressed/compressed
>> position report?
>> Finally, has anyone worked on combining the spec addendums with the spec
>> to form a coherent document? The editing process for that would surely
>> work out some of the bugs. I might volunteer to do this if it has not
>> been done and there is support for such a thing.
>> My notes so far are attached. The references section at the end contains
>> all the documents that were drawn on in order to put together the notes
>> so far, but as you'll see there are still lots of holes.
>> Thanks,
>> Iain.
>> _______________________________________________
>> 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/20200524/6eead7b9/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 24 May 2020 12:27:45 -0400
> From: Robert Bruninga <bruninga at usna.edu>
> To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
> Subject: Re: [aprssig] [TinyTrak] How to Contribute? (LA Basin
>   digipeating)
> Message-ID:
>   <CALdCfNJ8uF0wVdW1W6S6M2aQgjUs_A93VdnPd3fqoWPH1==zrA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
>>> On Sat, May 23, 2020 at 7:11 PM Clint Bradford K6LCS-3 wrote:
>> I am in Southern CA - (LA basin) and have a TT4, excellent external
> antenna,
> 
>> and at 5W hitting several other stations.
>> Is there a ?mode? I can place my setup in to contribute to the  system?
> 
> No, I assume the LA basin is saturated with digipeates from the very hig
> digipeaters that surround the LA b asin.  Back around 2004 maybe the total
> saturation of the LA basin was so bad that individual mobiles had a poor
> chance of getting heard.
> 
> So we suggested that all big digis on the mountains support ONE-HOP only
> and thus help eliminate all the out of area duplicity.  Now 16 years later,
> I realize I have never been to LA to see what is now actually happening on
> the air.  Did most digis implemetne one-hop only?  How's the channel sound
> now?  Just curious.
> 
> My other suggestion at the time if it was still bad was to make MOST of the
> mountain top digis be SPLIT FREQ.  Listening on 144.99 but still
> digipeating on 144.39.  This would greatly eliminate the collisions that
> mobiles were hitting while still providing 144.39 with all traffic.  A few
> digis should still listeen on 144.39 for visitors, but the advantage of
> reducing contention on the uplink could easiliy triple or more the capacity
> of the network.
> 
> Using 144.99 meant that a mobile in LA couild simply tune 144.39 but set
> the normal TX offset of +600 KHz.  The problem at the time was that someone
> else was using the 144.99 for something else.  I think maybe ATV audio?
> 
> Bob, Wb4APR
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200524/e4785a61/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Sun, 24 May 2020 17:30:41 +0100
> From: luis ramos abad <carrionas at gmail.com>
> To: aprssig at lists.tapr.org
> Subject: [aprssig] (no subject)
> Message-ID:
>   <CA+sb42PMAMp2JTT=n-zrmzdL94nNwBcvuis87tEx=30iA_-fOA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Darme de baja
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200524/05d0ebd2/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 4
> Date: Sun, 24 May 2020 11:34:33 -0500
> From: Gregg Wonderly <gregg at wonderly.org>
> To: Robert Bruninga <bruninga at usna.edu>
> Cc: Andrew Pavlin <spam8mybrain at yahoo.com>, TAPR APRS Mailing List
>   <aprssig at lists.tapr.org>
> Subject: Re: [aprssig] What is a position report?
> Message-ID: <F28B1C6A-B2A1-4FA2-A96F-88C75AFD97B8 at wonderly.org>
> Content-Type: text/plain; charset="utf-8"
> 
> 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.
> 
> Gregg
> W5GGW
> 
> Sent from my iPhone
> 
>>> On May 24, 2020, at 11:03 AM, Robert Bruninga <bruninga at usna.edu> wrote:
>> ?
>> 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.
>> Bob
>>>> On Sat, May 23, 2020 at 9:42 PM Andrew Pavlin via aprssig <aprssig at lists.tapr.org> wrote:
>>> Hello, Ian.
>>> I'm afraid you have a few misunderstandings, and a long uphill row to hoe to do what you're trying to do.
>>> 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.
>>> 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 aprs.fi has to support all of them, because it doesn't know who or what other stations the user is going to be working with.
>>> 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.
>>> 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 receiving-end 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.
>>> 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: "Be conservative in what you send, be liberal in what you accept". 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.
>>> 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).
>>> 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.
>>> 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).
>>> 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.
>>> 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.
>>> 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)?
>>> 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?
>>> Andrew, KA2DDO
>>>> On Saturday, May 23, 2020, 3:41:13 PM EDT, Iain R. Learmonth <irl at hambsd.org> wrote:
>>> Hi,
>>> In attempting to write code that produces position reports for stations,
>>> objects, and items I have ended up with some notes. They are far from
>>> being complete but I'm already starting to find some contradictions and
>>> perhaps some things that need changing now time has moved on.
>>> In particular, I think there needs to be some application of Postel's
>>> Law to the specs. We should determine what the correct thing is to send
>>> now, and what things you might be expected to receive. We should also
>>> consider what the correct thing to send might be in the future, and
>>> prepare implementations for that change.
>>> Items are not recommended in APRS 1.1, however this appears to be a
>>> mistake according to an email from Bob that recommends only against the
>>> compressed format for items, which I guess also applies to objects? So
>>> it's not really clear if we should be avoiding compressed formats
>>> everywhere.
>>> There is also the Mic-E format, which I haven't looked at at all yet. I
>>> wonder to what extent that can be treated as an extension to the APRS
>>> specification rather than a core part of it. Would it be recommended to
>>> implement Mic-E position reports over an uncompressed/compressed
>>> position report?
>>> Finally, has anyone worked on combining the spec addendums with the spec
>>> to form a coherent document? The editing process for that would surely
>>> work out some of the bugs. I might volunteer to do this if it has not
>>> been done and there is support for such a thing.
>>> My notes so far are attached. The references section at the end contains
>>> all the documents that were drawn on in order to put together the notes
>>> so far, but as you'll see there are still lots of holes.
>>> Thanks,
>>> Iain.
>>> _______________________________________________
>>> 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/20200524/4254f576/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 5
> Date: Sun, 24 May 2020 19:29:23 +0100
> From: "Iain R. Learmonth" <irl at hambsd.org>
> To: aprssig at lists.tapr.org
> Subject: Re: [aprssig] What is a position report?
> Message-ID: <6332554f-9578-c257-b947-076a61c2adea at hambsd.org>
> Content-Type: text/plain; charset=utf-8
> 
> Hi,
> 
>>> On 24/05/2020 02:42, Andrew Pavlin wrote:
>> 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.
> 
> It's too easy to fall into the trap of "we should support everything
> that ever existed". Decisions to not support things should not be made
> on a whim, but should be based on evidence that something is actually
> used. Nick's previous email regarding the precedence bit is exactly the
> kind of data that would be good to look at in making these decisions.
> 
>> 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 [...]
> 
> There are two things going on here. One is what you send, the other is
> what you receive. I would agree that you should be ready to receive any
> format currently in active use, but should be more conservative in what
> new implementations are sending.
> 
> Every extra format that you need to be able to decode is extra bugs that
> might be hiding. This is going to be especially true in the case of
> formats that are rarely used.
> 
>> 3. Amateur radio infrastructure changes _very_ slowly, because changes
>> come literally out of the wallets of individual radio operators. [...]
> 
> This only means you need to think longer term. Eventually, older
> hardware and software will be upgraded and replaced.
> 
>> 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?receiving-end
>> 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.
> 
> If it's possible to show, for example with APRS-IS data, that a format
> is not in wide use then I think it would be perfectly reasonable to not
> support decoding it.
> 
> I had not considered the position precision aspect, that probably means
> that my internal data structures for handling positions are inadequate
> as I started implementing uncompressed reports first.
> 
> I have tried to read about the !DAO! format, but couldn't get that
> document to load.
> 
>> 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:
>> "Be conservative in what you send, be liberal in what you accept". Jon
>> Postel _knew_ he was herding cats (to use the simile for managing
>> computer programmers). [...]
> 
> It would still be possible to describe use-cases where different formats
> are preferred. From the specs all I can see is that there are different
> formats, but no guidance to software authors as to which one should be
> used in which case.
> 
> Even if everything would have to be supported forever, you can still
> assess which things would be most appropriate to use in each use case
> and share that information.
> 
>> 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.
> 
> For these things, it makes sense that they exist outside of the
> specification as separate documents. There should be a responsible
> person/organization for maintaining them and there should be processes
> for updating them.
> 
>> 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).
> 
> In the majority of cases, software does not implement the whole spec.
> Working out which parts are core and which parts are extensions would
> help with consistency of implementations. Existing implementations would
> probably be the best thing to look at in deciding what is
> 
>> 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.
> 
>> From Bob's latest email, it looks like he'll be looking at this and I'm
> happy to not be responsible for it. I can provide reviews etc along the
> way if helpful.
> 
>> 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)?
> 
> There are indeed lots of programs available, but many of these programs
> try to do everything and often do not use modern best practices when it
> comes to security. Security doesn't just mean encryption, but for
> amateur radio systems means data integrity, preventing amplification
> attacks (e.g. via gateways or digipeaters) and preventing availability
> attacks on infrastructure.
> 
> I'm not writing anything to support connected mode AX.25, but rather
> supporting only UI frames in HamBSD. This is via a kernel driver. I'm
> also writing support for IP networking over AX.25 as a kernel driver. I
> am hoping to add support to Xastir, and potentially YAAC although I did
> not look at it as closely yet, for HamBSD's AX.25 interfaces.
> 
>> 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?
> 
> I guess for now there are already enough things here that I need to go
> back and address, but I'd appreciate a review of a future version of the
> notes. They will only be notes, and I'll leave any formal update of
> specs to be figured out by Bob.
> 
> Thanks,
> Iain MM0ROR.
> 
> -- 
> https://hambsd.org/
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Sun, 24 May 2020 19:35:22 +0100
> From: "Iain R. Learmonth" <irl at hambsd.org>
> To: aprssig at lists.tapr.org
> Subject: Re: [aprssig] What is a position report?
> Message-ID: <09febf0b-d748-b140-c868-861d69c4783e at hambsd.org>
> Content-Type: text/plain; charset=utf-8
> 
> Hi Gregg,
> 
>>> On 24/05/2020 17:34, Gregg Wonderly wrote:
>> 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.
> 
> I'm not opposed to the development of new protocols, or updates to
> existing ones, but the thing I was really trying to do here was figure
> out what the *current* spec says the right thing to do is. It's more a
> question of interpretation that a question of development.
> 
> In addition to OpenTrac, I'm also aware of XARPS in development by the
> Hudson Valley Digital Network.
> 
> Thanks,
> Iain MM0ROR.
> 
> -- 
> https://hambsd.org/
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Sun, 24 May 2020 18:50:45 -0400
> From: Nick VA3NNW <tapr at noseynick.com>
> To: aprssig at lists.tapr.org
> Subject: Re: [aprssig] What is a position report?
> Message-ID: <6f0c5bcc-5fad-62d5-4b5f-1a50e7acbe06 at noseynick.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Iain R. Learmonth wrote:
>> In particular, I think there needs to be some application of Postel's
>> Law to the specs. We should determine what the correct thing is to send
>> now, and what things you might be expected to receive.
> 
> I've had a bunch of similar Qs.
> 
> Does the "APRS Working Group" still exist or has it been disbanded? Does
> this mailing-list supersede it? If not, is it worth (re)forming one?
> What would one do to apply to get into an APRS-WG?
> 
> I've been doing a LOT of parsing of a LOT of APRS-IS captures recently,
> as part of wanting to get all the IRLP nodes on APRS (not just 10% of
> them running a defacto standard script, but ALL of them in a way that
> works usefully with TUNE/QSY buttons etc) and maybe revive the AVRS
> concept/server, but in the process I don't want to just create another
> non-standard-standard that's going to have other current/future
> developers pulling their hair out to work with the mess I've made.
>> Items are not recommended in APRS 1.1, however this appears to be a
>> mistake according to an email from Bob that recommends only against the
>> compressed format for items, which I guess also applies to objects? So
>> it's not really clear if we should be avoiding compressed formats
>> everywhere.
> Compressed are obviously FAR less human-readable, I mean about the best
> you could hope to do would be to recognise "Oh hey they share some of
> the most significant chars with me so might be somewhat
> local-ish-kinda". They seem to only make sense in those scenarios where
> you're trying to save every possible byte for things that will only EVER
> want to be machine-readable. Speaking of which...
>> There is also the Mic-E format, which I haven't looked at at all yet. I
>> wonder to what extent that can be treated as an extension to the APRS
>> specification rather than a core part of it.
> 
> Mic-E seems to be *THE MOST* severe attempt to pack as much as possible
> into the smallest packets possible. "Hey let's pack data even into the
> TOCALL"? :-D
> 
> I think the intention was that you'd pack a very short position report
> into a quick "chirp" on the end of your voice transmissions in place of
> an "over beep".
> 
> ... so I find it particularly hilarious when I find Mic-E with really
> long comments like...
> 
> '\xl X_/WX: 11,8V B4+05,68B3+04,00AT-03,62WT-03,62B2+03,00B1+02,25B5+06,75IT+01,93B6+07,31X1+02,06B7+07,50X2+04,81
> 
> ... which is NOT Mic-E telemetry even, just a really long Mic-E packet
> 
> Bob says:
> 
>> Note, Mic-E is used in evry Kenwood and Yaesu radio so it should be
>> the most important protocol to decipher first since that is the
>> majority of off-the-shelf mobiles.
> Well if you were just after sheer "bang for the buck", MicE is way down
> the list - a typical day in April saw:
> 
> 6096737 packets, which start...
> 1614069 ! (position, of which...)
> 1600658 !n (probably uncompressed)
> 1315009 ; (object, of which...)
> 1307698 ;ValidName* (valid object name, and not killed, of which...)
> 1307668 ;ValidName*n (valid named not-killed obj probably with uncompressed position)
> 849295 @ (time+position, of which...)
> 848013 @nnnnnn (have a 6-digit timestamp, SOME of which might not be valid but...)
> 738602 @nnnnnnz (DDHHMM Zulu/UTC)
> 100901 @nnnnnnh (HHMMSS Zulu/UTC)
>  4264 @nnnnnn/ (DDHHMM local)
>  5528 @something-else (various invalid timestamps EG @Greetings or @yyyy.yyN/xxxxx.xxW)
> 834407 @nnnnnn[zh/]n (probably valid object, uncompressed pos)
>  8261 @nnnnnn[zh/][\/] (probably valid object, compressed pos, main/alt symbol tabs)
> 640626 = (position, message-capable, of which...)
> 619533 =n (probably uncompressed)
> 341197 : (messaging)
> 341191 T (telemetry)
> 283104 > (status)
> 270164 ` (Mic-E with GPS fix)
> 109269 < (capabilities)
> 75077 / (time+position)
> 74072 ) (Item)
> 52309 ' (Mic-E with old GPS fix, I think)
> 33037 _ (positionless WX)
> 13773 $ (NMEA / Ultimeter2k)
> 10114 U Starting to get into packets without type-chars here like:
> <CALL>-2>UIDIGI,qAR,<DIGI>-1:UIDIGI 1.9
> <CALL>-10>UIDIGI,qAR,<DIGI>-12:UIDIGI 1.9
> 
> I say "probably uncompressed" but if some of the symbols are allowed
> overlay chars of 0-9, we presumably need to parse further to decide if
> this is a valid Pos, Compressed Pos, or garbage?
> 
> In any case, if your goal is to "decode as much APRS-IS as possible",
> start with uncompressed positions, then timestamps (because that's the
> same with a prefix), then objects (another prefix before that) and
> you've already got 70% of packets on APRS-IS. Be a bit more tolerant of
> objects with invalid name lengths and you'll get a few more. Add items
> (objects without timestamps but variable name lengths) and you're well
> on your way to 75%. Mic-E is honestly only 5-6%, although Bob could be
> right about "majority of off-the-shelf mobiles" if most of them are
> non-mobiles, especially considering "a typical day in April" is actually
> April 2020 during covid lockdown and there might be much less mobile
> activity than normal? (Hmmm, THERE'S an interesting idea for a research
> project!)
> 
> Expect A LOT of crap packets - I've already mentioned objects with
> inappropriate length names, but packets with no/invalid types, packets
> with Longitude like -12.3456W (WAT?), non-ascii symbols, plenty of
> overlays on symbols that probably aren't supposed to have overlays, all
> sorts of things wrong lengths or in wrong places...
> 
> EXTENSIONS are messiest of all. The spec implies you get ONE of them, so
> are you allowed a CSE/SPD (course and speed) AND a PGHphgd (power,
> height, gain directivity?) AND a /A=nnnnnn (altitude in feet)? Is
> /A=nnnnnn allowed ANYWHERE in the comment? There's an example:
> 
> !4903.50N/07201.75W-Test /A=001234
> 
> ... so presumably mid-comment or end of comment? So is this (genuine
> packet) legal?...
> 
> !12.34.56NR12345.67W&/A=000348PHG0430/iGate
> 
> Even if it's not legal, should we attempt to parse it, or abandon all
> hope? Does /A=123456 have to be 6 digits? How would/should we handle (say)
> 
> /A=12345Short test?
> /A=1234Shorter test?
> /A=-00012 Negative OK? Is it above mean sea level or above ground or above terrain?
> /A=1234567 Over-long OK? If so...
> /A=00123444.123MHz ?
> 
> Max 999999ft altitude (FEET?!? that's a different argument, but I'm just
> going to point out that only 5% of the world still uses imperial units,
> despite most of those 5% having cast off their imperial shackles 244
> years ago... where was I...) 999999ft is good enough for most (all?)
> High Altitude Balloons, but not enough for LEO satellites, ISS, never
> mind geosynchronous, would be nice to know if it's OK to use more digits
> or not.
> 
> How about all the weather extensions - are they ONLY allowed on packets
> with symbol "/_" or type-char "_"? If other packets look like they have
> WX info despite other symbols, should we attempt to parse it?
> 
> WX dir/spd (or cnnnsnnn in positionless wx) and "gust" and "temp" seem
> to be mandatory but are allowed to be spaces or "." if not available. Is
> "0.3" acceptable? The various rains rnnn pnnn Pnnn hnn bnnnnn (or bnnnn
> depending on what you're reading) are optional, but for all of these,
> does ORDER matter, or am I allowed p123g123b12345t123? The L/l
> luminosity, s snowfall, # raw rain counter, do they have to appear AFTER
> the others, in that order? How long are they allowed to be? If someone
> sends r4p0P3 (much too short) should I assume corruption or try to parse
> as r004p000P003? In which case how was there more rain in the last hour
> than there was since midnight, when there's been none in the last 24hrs?
> 
> ... and should /A=123456 or PHGphgd appear before, after, or in the
> middle of the WX data? What if they do all of the above?
> 
>> Finally, has anyone worked on combining the spec addendums with the spec
>> to form a coherent document?
> Not as a document, but somewhat in parser form.
>> The editing process for that would surely
>> work out some of the bugs. I might volunteer to do this if it has not
>> been done and there is support for such a thing.
> Smells like a job for a small-ish APRS-WG, hence my Q
>> My notes so far are attached. The references section at the end contains
>> all the documents that were drawn on in order to put together the notes
>> so far, but as you'll see there are still lots of holes.
> 
> Spot the RFC editor?? ;-)
> 
> Y'know what, this COULD BE and RFC it is after all (at least part of) an
> Internet Protocol.
> 
>> ?? It is intended that inanimate things are reported as items, while
>> ?? things that move are reported as that reported as objects.
> Is it? I think you got that from APRS101 p57, but all examples of
> repeater objects seem to be OBJECTS not ITEMs. I suppose some repeaters
> can get quite animated though?? ;-)
> 
> I've always thought "Does it benefit from having a timestamp? If so,
> object", and it could be argued that repeater objects benefit from
> having a timestamp if that shows "Was idle/busy/offline at this time"
> but then I find http://www.aprs.org/info/object-perm.txt which suggests
> using an object with a timestamp of 111111z, which...
> 
> A) Is then different from an item how? Just in name length/padding?
> B) Is a perfectly good timestamp for real objects updated at 11:11 on
> the 11th day of the month. Are they accidentally permanent unless
> otherwise updated later?
> C) I've also seen 000000z in use - midnight at the start of the ZEROth
> day of the month? Nice idea for a deliberately invalid time, can't
> happen accidentally, but should this be treated as permanent, or
> unknown/undefined, or something else?
> 
>> Nick's previous email regarding the precedence bit is exactly the
>> kind of data that would be good to look at in making these decisions.
> 
> Happy to help - I seem to be the self-proclaimed APRS big data
> statistician?? :-D
> 
> Nick
> 
> -- 
> "Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
> use Std::Disclaimer;    sig at noseynick.net
> DOS: Defunct Operating System
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200524/586fb63c/attachment-0001.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
> 
> 
> ------------------------------
> 
> End of aprssig Digest, Vol 191, Issue 22
> ****************************************