[aprssig] AX.25 RR bit test - Holy Grail (KWD)

[Robert Bruninga]

Kenwood confirms that their radios all will ignore the RR bits and so we
can use them for future features without impacting current functions.

I will keep tabs of the results of all tests of the RR bits as we prove
that
The network is presently transparent to their future use.  Please test and
report.

I have now added both of these new proposals (Preemptive digipeating and
RR bits) to the APRS version 1.2 web page:
http://aprs.org/aprs12.html

Bob, WB4APR

-----Original Message-----
From: Robert Bruninga [mailto:bruninga at usna.edu]
Sent: Friday, November 30, 2012 3:07 PM
To: TAPR APRS Mailing List
Cc: Robert Bruninga
Subject: RE: [aprssig] AX.25 RR bit test - Holy Grail (reply)

Your comments are all well received.  But so far, none of the comments
have shown a reason why not to explore future use of these bits for future
constructs:

> it would not work with existing software..

Never intended to "work".  Only intended to be "transparent" or "ignored"
by existing software.  The Future use of those bits is only for FUTURE
concepts which of course would require FUTURE code to take advantage of
it.  But nothing that exists now would be impacted (if present hardware is
AX.25 compliant and transparent to them as they should be).

> these bits are in AX.25 headers. _not_ in
> [packets] sent through APRS-IS...

SO therefore, by definition, they do not break anything that exists in the
APRS-IS and are 100% backwards transparent with the entire APRS-IS.  It is
only backwards transparency that is a concern.

> Also, there is no construct in the APRS-IS packet
> format to embed the values of those bits in the APRS-IS...

Sure there is.  We can easily add into the APRS-IS pseudo header without
breaking anything that exists.  I am sure that the clever minds that came
up with the Q construct can think of some similar way to indicate these
bits [11].

> and not available in any clients speaking to command-mode TNC's.

But again, "are not available" does not block any future use and also
implies existing transparency.

> Only KISS-mode TNC's would be able to pass such non-standard packets

First, GREAT!  This means that every software or client that uses a KISS
interface can be updated to use these bits if desired.

Second, these bits *are* STANDARD AX.25.  "The bits ... may be used in an
agreed-upon manner in individual networks".  And if that is not APRS, then
I don't know what else would be..

> There's just WAY too many things using the TNC2
> humanly readable packet format, not just the APRS-IS,
> that would need/benefit from access to this information.

Again, that is FUTURE BENEFIT.  Of course, FUTURE code would need to be
updated to take advantage of FUTURE use of these bits.  But that is how we
move forward as long as it does not break anything that exists now.

> But to me the death knoll is compatibility.
> There are just too many devices for this to ever
> be proven not to be harmful.

They are in the spec, the spec authorizes their use, every spec compliant
TNC, Radio, Hardware, etc should handle them just fine.  We should not be
afraid to use something in the AX.25 spec that was put there just for this
kind of special network use, but we overlooked for so long? We simply need
to test them before using them.

Of course, we would not move forward if ANY existing hardware failed to be
transparent to these bits.  But that is no reason not to at least perform
the test and find where we stand.

> I urge you to withdraw this part of the proposal...

But, until someone can show that a piece of hardware fails to pass these
packets, then I think it should remain on the table and worthy of
exploring and testing.

So few of us can actually generate an AX.25 packet at the bit level, that
this testing can only be done by people who can test their AX.25
transmitting code.  Maybe Byonics or Argilent, or any of the software TNC
authors can take a crack at testing it.

So again, the only thing that matters now is TRANSPARENCEY of these bits
to all existing APRS and AX.25 hardware and firmware.  Future use that
does not break anything that exists, seems to me to be a worthy area to
explore for future use for future (not presently existing) capabilities.

Just brain storming...

Bob, WB4APR