[Dxspider-support] 7QNL

[K2LS]

Dirk,

Thanks for the many years of service.


I also have a problem.  I can not sign into my node when operating as 
4X/K2LS.

I for one would greatly appreciate the changes necessary so I (we) could 
do this.

73, Larry  DXC.K2LS.COM


On 3/16/2014 9:53 AM, Dirk Koopman wrote:
> 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
>
>
>
>
>
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>