[Dxspider-support] 7QNL

[Dirk Koopman]

On 15/03/14 20:39, Peter wrote:
> Hi
>
> The problem Remco is faced to is that he can't login with the 7QNL call
> sign into a dx-spider node.
> The dx announcement with a 7QNL call is OK.
>
> I think the client in /spider/src needs some modification to allow 7QNL
> to login:
>
> login: 7qnl
> Sorry 7QNL is an invalid callsign

Peter: I take it that you are still using the C client because you have 
ax25 users? If you don't use ax25 then please could I ask you to stop 
using it because a) it isn't necessary and b) it means that I only have 
to make any changes in one place.

>
> For th time being, AR clusters do allow 7QNL to loging

I need to let off some steam. Apologies if this offends anyone.

<rant>
Some people, when they write software, try really hard to validate 
important credentials in order to protect the environment that have to 
operate in.

Now I know that I am bit touchy about callsigns, but there are some good 
reasons for this. The main one being that I know that there is software 
out there that will not cope well (or at all) with callsigns (in certain 
protocol fields) that are not standard.

This *may* be an out of date view but, having been on the receiving end 
of a *lot* of abuse for "not obeying standards" in the early years of 
DXSpider, I have always been very reluctant to mess about with the 
callsign validation code.

But is seems that one country has decided to allow a non-standard vanity 
callsign, which will open the floodgates for others to allow themselves 
to be pressurised into similar deals. All bets are then going to be off.

I predict that we shall be soon seeing dxspeditions or contest callsigns 
of the form KA->KZ, PAA and similar abominations - all uncheckable 
without a load of extra processing that is currently handled (in my 
code) by a couple of (fast) regexes. And this, all in the name of 
"speed" and "efficiency" in (whisper it very quietly) morse code and 
that missing second digit takes sooooooooo long to transmit.

I was under the impression that international callsigns and their 
structure was governed by strict ITU regulations. Clearly I was being 
naive (and not for the first time).
</rant>

But for now I am rather inclined to say that if 7QNL wants to use an 
AR-C node for access, then go you right ahead. But please bear in mind 
that (whatever I might do myself) the majority of the network will 
continue to use older code which, in turn, will REJECT ANY PROTOCOL 
SENTENCES WITH AN INVALID CALLSIGN IN ANY OF THE "FROM" FIELDS (such as 
originating callsign or node).

N.B.: This is not explicit cussedness on my part, but merely the effect 
of the inertia of most sysops not bothering to update software - how 
ever often I nag - unless I force them to do so. Usually by making it 
very difficult or tedious to carry on using the old stuff.

Could I remind sysops that this sort of checking stops (or at least 
raises the bar for the creative) a lot of the abusive callsigns that 
used to appear on the network.

As you may be able to tell, I am not happy. I will have to consider my 
position further. But my initial response is this: I would be prepared 
to do something like allowing 7Q/G1TLH (or G1TLH/7Q) style callsigns on 
login (which have the merit of some standardisation) rather than 7QXX(X) 
style callsigns (from whichever country is prepared to be bamboozled 
into allowing similar ones). And I don't want to go down the road of a 
load of "exceptions" either.

Even if I do do this, the "inertia" factor will stymie any modification 
and the output of these callsigns will *still* not be well distributed 
if people don't update.

Dirk G1TLH