CQ-Contest
[Top] [All Lists]

[CQ-Contest] eQSL change of policy

Subject: [CQ-Contest] eQSL change of policy
From: k1mk@arrl.net (Michael Keane, K1MK)
Date: Fri Apr 5 12:22:49 2002
Jim,

Jim Idelson wrote:

> However, if there is a desire to increase the rigor in QSL
requirements for 
> DXCC and other awards, such a decision and discussion should be taken
up by the 
> DXCC team with significant input from those involved in the DXCC
program. It 
> should not be implemented via an end-run by the QSL technologists.

That rigor would appear to already be there, at least in public
statements if not enforcement.
 
The DXCC Program has characterized preemptive QSLing even with paper
cards as a "poor QSLing practice" that should be discouraged; at least
when it's practiced by rare DX stations. 

Now, it doesn't seem to be of much concern that individual contesters
from "common" entities preemptively send out multiple thousands of
unsolicited cards via the bureau annually. A very low percentage of
those cards are likely to ever make their way back in an appliction to
the DXCC Desk (or field checking).

Also, with paper cards the fact that the first of two cards exchanged is
an unsolicited confirmation doesn't seem to matter. The initial card in
an exchange of QSLs is typically not the one with which the DXCC Desk is
concerned, particularly at the higher achievement levels.

Likewise, responding to incoming cards without consulting a log is
another example of what was described as "poor QSLing practice". It
might be seen as a courtesy or convienience when practiced between
stations in non-rare entities, but if it became known that a station
from a "rare" entity sent out cards without checking a log or didn't
keep a log, DXCC credit for contacts with that station might well be
denied. 

Yes, those would seem to be very much of a double-standard; which are
not internally self-consistent. If DXCC has a more rigorous set of
self-imposed standards (or suggested practices) for how QSLs from "rare
DX" should be generated which differ from the typical practices employed
by us "commoners", then it should not be that much of a surprise that a
single, uniform protocol enforced by LoTW would be based upon the
higher, more rigorous standards and suggested practices of the DXCC
Program rather that emulating the practices in common use. 

Remember LoTW is firstly a front-end for DXCC and other ARRL awards
programs. It satifies the requirements needed to perform those functions
very well. But it is not necessarily the best or most general model for
how to define and implement an open standard for portable, forge-proof
electronic confirmations. 

> The current approach might be great for the dedicated, web-savvy,
hard-core 
> DXers among us; but it is not going to be particularly attractive to
the 
> newcomers and casual operators that dominate our ranks. The
requirement to 
> upload electronic logs in order to receive QSLs will filter out
thousands of 
> potential users.

The current approach would not prevent a casual user from sending QSO
information for a single contact, just like sending an individual card. 
Could easily do that from a web form: type in your QSO data, click send.
Anyone can create their own version of what they think this UI should
look like because the upload is by means of e-mail or http. And the
upload could even go via a third-party since it does not have to take
place over a validated or otherwise secured connection.

Unless there is a change in philosophy what is unlikely to happen is to
be told "You've Got QSL" and be provided with the full QSO details. 

> Want to ensure that confirmations of rare DX QSOs are harder to forge?
Put 
> special requirements on certain DXpedition logs, extremely rare
countries, etc. 

How about only requiring the user submit double-blind matching QSLs for
new band/mode countries? Might work if LoTW were only intended to be
used for DXCC. It's not. 

Plans are to expand LoTW to include the other ARRL awards programs, so
you'd need to also exclude viewing of unsolicited, unmatched QSLs from
new states, grids, etc. Over the longer term there is a consideration of
marketing LoTW data or awards checking services to outside customers.
Can't compromise the integerity and potential marketability of the
database, so the genie can never be let of the bottle. 

This whole issue of double-blind originates with the scenario that by
going to electronic confirmations will make the QSLing process so easy
and inexpenisve that preemptive QSLing will become the norm. Why go
through the trouble of checking each card, just upload the logs? It
helps out the other guy, right?

As a result, the thinking goes, many of the "undeserving" will start
receiving unsolicited confirmations for contacts they didn't make
because of the inevitable busted call signs. Remember those? This is
CQ-Contest after all. Some of the weaker individuals out there might be
tempted to submit those unearned confirmations for award credit.

It can happen just as easily with a bureau card despite preemptive
QSLing having been labeled a "poor" practice. It doesn't happen very
often only because most of the rarer DX don't send out a card for every
contact via the bureau; yes, some do. 

As I recall, one goal of LoTW was to come up with a process for
electronic conformations that was "more secure" than paper QSLs. Going
double-blind closes off giving out credit for a busted call. Just like
contest log checking.

It's yet another attempting to have a machine enforce ethical behavior.
It's a people problem. Other than personal integrity, there is nothing
to stop two individuals from consipiring to falsify a contact, under the
present system or any future system. But the machine can stop an
individual from fraudulently taking advantage of some else's error. Is
it worth it the inconvience?

Anyone got a different solution? 


> But, please don't introduce log transcription or upload requirements
just so we 
> can see the QSL for a 20M DL QSO.

Well, I guess we're not supposed to look at the unsolicited DL cards
that arrive via the bureau, either. :-( 

73,
Mike K1MK
k1mk@alum.mit.edu

Michael Keane K1MK
k1mk@arrl.net
________________________________________________
PeoplePC:  It's for people. And it's just smart. 
http://www.peoplepc.com 

<Prev in Thread] Current Thread [Next in Thread>