[aprssig] IGate wildcards/Telpac data

[Steve Dimse]

First, I have an embryonic Telpac page set up:

http://www.findu.com/cgi-bin/telpac.cgi

An issue has come up in discussion of the subject of the Telpac objects, I think
the general APRS community should discuss this. First a little background...

Initially I was very much opposed to the use of wildcards in IGate blessed
callsign lists. I felt that the danger of someone entering a bad wildcard call
and flooding the local network outweighed any benefit. However, when Dale
started sending the weather warnings, that changed, the ability to gate
wildcards was needed to take advantage of this cool feature.

The situation with telpac nodes is different. Currently, they are being sent as
objects with the callsign and object names the same. The proposal is to change
this to sending with a prefix of WL-...so for example, if I had a node the
packet might look like:

WL-K4HG>APWL2K:;K4HG-11:.......

The idea here is to use a wildcard in the IGate to send out all telpac nodes. In
order to avoid flooding the local area with these packets, the IGate would need
to use a filtered port set to an appropriate radius to be sure that only local
nodes were sent to RF.

In theory, this will work fine. In practice, it is virtually certain that some
IGates will run WL-* in the IGate list, and end up on an unfiltered port,
flooding the IGates.

I am very much opposed to this because while I think the telpac node information
on RF is a very good thing, any excessive gating to RF is guaranteed to create
controversy, and in the end will harm efforts to get Telpac, Echolink, and other
ham system objects integrated with APRS.

My feeling is the real callsigns should be used for these objects, and an IGate
operator should need to enter each one manually into his code. There is always
the option for IGate programmers to add the ability to detect these packets
themselves, and send out ones within a set radius. I just think the wildcard is
too dangerous to accept. Another problem is this would prevent the deployment of
any KISS IGates in the future. These would have the effect of shortening the
IGated packets, and even though no IGate currently uses this, I think it is
foolish to throw this possibility away.

Currently, findU is blocking this plan because of a long-standing (meaning I
didn't add this to block the plan, it was added years ago to prevent the -NET,
-HOME, -IP SSIDs that were becoming problematic) requirement that callsigns be
AX-25 compliant. If the community does not object to the WL- plan, I can and
will remove the restriction.

What do you think?

Steve K4HG