[aprssig] APRX aprs-is filtering

[Bob Bruninga]

Pete, et al

Thanks for the explanation.  But this messaging issue is something I would like to explore further.  It seems to me to be a "potential issue" with respect to the intent of APRS messaging.

> No as this was never discussed as a requirement 
> back when IGate support being reviewed.

My recollection is that the APRS-IS evolved without any spec or leading document.  Any attempt to do so was fought bitterly by some of the APRS-IS authors...  Thus, it just happened without specific detail concern over all aspects of APRS.

> One major reason: most IGates don't gate to RF 
> all messages for a received callsign and this, 
> I believe, is on purpose.

I think we need to explore this.

> Yes, a client "should" display all messages 
> seen for the client's callsign.  Most display 
> these messages independently of messages 
> specifically for the station and the station 
> "must not" acknowledge any messages for stations 
> [SSID's] other than itself.

True.

> In the RF world, this seems like a simple 
> issue but becomes very complex and potentially 
> hazardous when you introduce geographically 
> diverse stations running under the same 
> [root] callsign.  Because most if not all IGate 
> software at the time of the design of the IGate 
> support in javAPRSSrvr did not gate to RF except 
> for last heard stations and because the 
> discussions at the time solely focused on 
> providing proper APRS messaging support for 
> stations recently heard on RF, the IGate support 
> in javAPRSSrvr also focuses solely on APRS 
> messaging support for stations recently heard on RF.

Yes, "recently-heard" still applies...  Today, for example, I am in Utah at a conference with my WB4APR-7 HT.  I drove to the airport in my WB4APR-9 and my home station or work station are also on the air.  I expect a message sent to ANY of my WB4APR stations (if seen by an Igate near me) to send it out to RF including my HT in UTAH.  I use "expect" in the future sense, because as we are learning, this is not presently the case).

I DO agree with the need for an option (defaults to ON) so that someone can turn off the delivery of messages to some SSID's.. though that adds even more complexity..

All of this requires the local UTAH IGate (and filtered server) to recognize that WB4APR-7 is locally heard in Utah, and that ANY message on the planet sent to WB4APR[any SSID] to be gated to RF here [where I was recently heard].

> Once again, the "intent" of the spec and actual 
> implementation by software authors are apparently 
> divergent in this area.

Yes, and thanks for raising this issue.  Actualy I had not thought about it before... but it does (as you say) open up some issues... that we should nail down for the future...

> Personally, I don't think it makes sense 
> to risk potential RF network issues by 
> implementing this,..

I admit, that I may not be thinking of all the possible down-side issues, but maybe we should see if we can identify them... and see if they are surrmountable...

> especially since most of the IGate software 
> in use today (over 90%) would not gate those 
> messages to RF anyway (and most of the IGate 
> software is no longer modifiable either).

Which is a crying shame, but true.  But we need to be looking in the long term future.  And as I continue to drumbeat the idea of universal Ham Radio Text messaging (see www.aprs.org/aprs-messaging.html ) and more and more radios are coming out with built-in APRS messaging, we probably outta nail this down..

Bob, WB4APR

>> From: Robert Bruninga
>> Sent: Friday, August 06, 2010 5:25 PM
>>
>> That is a good thing to check....  It is in 
>> keeping with the intent of the spec, that a 
>> person goes from base, to mobile to HT, to 
>> blackberry at any time, and so his messages 
>> were intended to be copied by all his stations.  
>> Thus, the Igate (and filtered server) should 
>> return to RF any such message as long as 
>> there is ANY of his SSID stations in the 
>> local area.