[aprssig] Gating Objects from Internet to RF (Really Final?)

[Bob Bruninga]

> Unless someone can come up with a 
> good technical reason for not using 
> the station's call, I'm going with it.

Im surprised at that sentence...  I, and others have given you at least 5 or 6.  And they are very valid!  And I dont think you have given any valid reason why you want to do it, that has not been soundly refuted.  Even the person who made the comment on which you based your decision has rescinded his meaning.

>> I recommend that you make ALL 
>> of these objects be originated by
>> your callsign... Something like KE4ERJ-EL.  

> I'm loath to use a non 1-15 SSID as 
> the fromcall.  I know it is technically 
> possible, but it can restrict others 
> from possibly gating the packet 
> directly to the RF..

No, anyone can do it anytime.  That is why we have the 3rd party format.  And this has been debated over the years, and there is no techincal reason why a packet injected by a NON-TNC cannot fully use the 9 byte originator field.  Yes, we prefer to see an SSID format.  If you dont like -EL then you can use any 1-15 SSID with your call that you want if you want to preserve that.

> rather that providing a full 3rd party 
> packet wrapper which would be necessary 
> for the -EL SSID suggested.

My objection to ECHOLINK is that I think it is unfair to the EchoLink author who will feel as though his system is being spoofed.

Back to using the NODE CALLs.  I hope we have put that to bed.  Everytime we debate this kind of SPOOFING a packet onto RF or even directly into the APRS-IS, we have all eventually come to the same conclusion that it is illegitimate and violates the fundamentals that that field is ONLY there for the SOURECE of a packet, not there for someone to SPOOF a source.  As you can see, all the major players on the APRSSSIG agree completely with not SPOOFING other peoples calls into packets they did not originate.  Period.

>> 2) PHG data:
>>   
>> PHG should not be included in these 
>> objects in any case... will show up 
>> as TEXT "PHGxxxx" pushing the other useful
>> information another 8 characters off the screen.

> I'll disagree on this one.  
> If the FREQ isn't valid, all bets 
> are off on "reasonable" displays.  
> I'd rather get the PHG visible on 
> APRS-IS since the FREQ isn't usable 
> on the mobile anyway.

OK, I'm not sure I agree, but you have a valid point.  SO you can keep that one... It doesn't break anything...

>> 3) Actually, I would rather see 
>> all non-standard entries DUMPED to
>> a NEEDS-FIXING file...

> If I dump it, no one is likely to 
> ever know (especially possible users).

True.  I guess I menat that it would still be transmitted so that we all could see the error too.  SO I think we agree here.

>> 4) I see lots of these showing 
>> [offline] but not showing an offline status 

> you will eventually find a record...
> The <location> (status) is [offline], 
> but the <status> is N and the 
> <status_comment> is On...  Go figure.

I figure the [offline] comes from the server that has not heard from it in a long time, where as the ON was the last state reported by the node.

SO, to solve the BIG FLOOD problem, lets not send ANY node that indicates OFFLINE either [offline] or in the status. It will fade from view.  that eliminates a lot.  We wont send any KILL packets either when we see the change.   That also reduces load...

>> 5) Do you see anything to fix on the Echolink side?...

> About the only thing I can think 
> of is to somehow make sure that the 
> frequency they enter is in MHz. 

Great idea!

Bob, WB4APR