[aprssig] Universal Messaging (and new qAP feedback?)

[Robert Bruninga]

>> Subject: [aprssig] Universal Messaging (and new qAP
feedback?)
>> 
>> Maybe it could be a new "qAP" packet.  
>> Following the "qAP" would be the callsign 
>> of the Igate, then its RF PATH...
>> This kind of feedback on the APRS-IS 
>> would be very valuable.  
> 
> Please do NOT make ad-hoc changes to 
> the q algorithm.

Pete, thanks for taking a look at this.  I'm not proposing that.
I'm only asking those people in the best position, such as
yourself, to figure out how to do it.  I only suggested
something like "qAP" as a starting point for further discussion
and development.

> ... All q algorithm enabled servers depend 
> on the integrity of this construct.  
> Deviations such as you proposed here will 
> break APRS-IS.

Then help us come up with another way for Igates to send back
feedback onto the APRS-IS on how they handled a packet back to
RF.

> ... this "let's throw this against the wall 
> and see if it sticks" type of posting can 
> cause significant damage as people who are 
> not knowledgeable of how APRS-IS and its 
> components work blindly follow these lines of 
> thought break what the network.

I don't think so. We throw ideas like this against the wall to
let those that are knowledgible then mold it, and re-work it to
something that can work based on their broader understandings...

> Your proposal is a solution looking for a problem.

I don't think so.  It is the number one problem in the APRS-IS,
and that is the complete lack of any visibility to what an Igate
does with an APRS-IS to RF packet.  That is a very real and
dead-end problem that has held back so many potential
improvements in APRS-IS for a decade.  It is a problem, and I
think we need to find a solution (that will not break anything
existing)... But that can lead to a more deterministic network.

> Looking at raw packets (available on most 
> of the APRS database servers) will readily 
> tell you many things:
> -Was the message generated?
> -Was the message numbered or unnumbered?
> -If numbered, was an ack seen from the receiving station?

But the most important info that we cannot see now are:
1) Did any Igate send this to RF?
2) Which Igates sent this to RF?
3) Where are those Igates?
4) Was it a 2-way or 1-way Igate?
5) What path did that Igate us on RF?

> Because of dupe checking, all RF activity 
> (digipeat paths, etc.) need to be viewed 
> on RF.  APRS-IS has never been a useful 
> tool for RF diagnostics because its entire 
> premise depends on duplicate payload 
> packets being dropped.

Which is exactly why we need to fix this and why we need this
FEEDBACK packet generated by the Igates to send back to the
APRS-IS what it did with the packet.  I am suggesting something
like this:

FIRST, there are many "rules" for what message packets get sent
from the APRS-IS back to RF.  And each Igate does it
differently.  We need to clearly define these processes.  And
give them an ID.  Something like:
-GL means "gated because it fit the "local" rule.
-GC means it was gated because it was a special CALL
-GO means it was gated because of "other" etc...
-GE means it was gated because of etc...

THen when an Igate sends that message to RF, it generates an
APRS-IS packet that feeds back not only that "rule" info, but
also the RF PATH that it used.  I suggested adding this to the
"q" construct, but if that breaks something, then lets invent
something that won't.

I don't care how we do it.  We just need to get it done.  If you
can come  up with a way, I am more than happy to see how it can
be done without breaking anything, yet paving the way for the
future integrity of the APRS network.

Who knows. Maybe we could even get it added back into Uiview
Igates with an add on?

Bob, WB4APR