[aprssig] What is a position report?

[Iain R. Learmonth]

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/