> from Pete, N4ZR
>
> I've been having a little dialogue with the guys at SK0UX regarding E-QSLs,
> which has devolved into trying to figure out an easy way to resurrect the
> practice of having contest QSOs count for awards without having to exchange
> QSLs, as was the case during the 50s-70s.
>
> It seems to me that the only thing that should be required is for the
> awards people to have access to a database containing a list of the calls
> TF3IRA (for example) worked on a given band.
>
> snip
Pete -
This is a repost of a proposal I made last year about this time...it seems
like the technology available is getting closer to making this a solvable
problem.
73, Ward N0AX
---
Before re-designing the system, one must ask, "What are the requirements?"
Fortunately, we already have a system that is fairly reliable, so a total
definition of all the functions is not needed. It should be possible to
say, "The new system should function just like the old system with
specific improvements and no degradation in confirmation controls."
I see the problems as:
1) Speed and expense of confirmation - the current system is fairly well
controlled but slower than molasses and expensive to all concerned.
2) Confirmation by an authorized party (i.e., QSL manager) - The parties
in charge of "supply" (the DX) need to be in absolute control of the
confirmation request. The suppliers must be the ONLY ones able to confirm
the QSO as requested by the demanding station.
3) Verification of authorized confirmation by awards organizations - The
parties in charge of granting awards must be able to verify that the
QSO was, in fact, confirmed by the suppliers.
The careful reader will realize that this is an exact analog of the
financial transactions associated with credit cards as an improvement over
paper checks. The banks and merchants are currently wrestling with
parallel issues over transaction verification. Electronic signatures and
sender/receiver ID protocols have to answer the same questions.
We don't have to have the same level of security as for financial
transactions, but the problems are the same.
Let's throw out the following protocol as a straw-man to critique...
(To keep the verbiage from getting stuffy, 'N0AX' will represent the
'demander' who requests confirmation, 'DX1S" will represent the
point-of-control for granting confirmations...the QSL manager.)
Step 1 - DX1S prepares a log data base and a search engine capable of
reporting the following degree-of-match parameters: Date, Time, Callsign,
Frequency. DX1S also sets a minimum degree-of-confidence level for which
confirmations can be generated automatically by a confirmation manager
program. For example, DX1S sets up the search engine to automatically
report a match for the following conditions:
Call & Band - exact match
Time - plus/minus 10 minutes
Step 2 - N0AX sends a private query message to DX1S containing the usual
QSL infomation: Call Date Time Frequency
Step 3 - The DX1S search engine generates a report with degree-of-match
for all confirmation parameters.
3A - If the manager program finds that all confirmation parameters
match the log data base with a degree-of-confidence greater than the
pre-established minimum, then a confirmation record is posted to a
data base of confirmed QSOs. A confirmation message is also
returned to N0AX. The confirmed QSO is marked as "confirmed by
N0AX" in the log data base to prevent multiple confirmations for
a single QSO.
3B - If any of the confirmation parameters fail to exceed the
minimum degree-of-confidence, then the confirmation request and
the search engine report are stored in a separate data base for
review by an authorized individual. A review-pending message is
returned to N0AX.
3B-i - If DX1S determines that N0AX's mis-match is due to
a DX1S logging error, than the appropriate confirmation
message is generated as in Step 3A.
3B-ii - If DX1S determines that N0AX's mis-match indicates
that a valid QSO was not made, then a "confirmation denied"
message is sent to N0AX and nothing is added to the data
base of confirmations.
Step 4 - N0AX sends the confirmation, identifying DX1S' confirming data
base, to the awards organizations. Matching programs at the awards
organizations compare the confirmation request received with the
confirmations listed in DX1S' data base. Because the requests should be
identical to those posted by DX1S, all information should match
completely.
4A - N0AX's confirmation request matches that posted by DX1S.
A "confirmation accepted" message is sent by the awards
organization and the award data base is updated.
4B - N0AX's confirmation request does not match DX1S's data
base. A "confirmation mismatch" message is sent automatically
from the award organization's matching program to DX1S who reviews
N0AX's request to the awards organization with the DX1S data bases
and replies to the awards organization to accept or deny the
confirmation reported by N0AX.
This type of automatic search-and-report system would automatically handle
a large percentage of confirmation requests. Whenever a discrepancy is
found, a human reviewer enters the process and can make the appropriate
decision.
The major flaw in this scheme is for DX1S to set an insufficiently
strict minimum degree-of-confidence. If the degree-of-match for an
automatic confirmation isn't required to be sufficiently strong, then bad
QSOs might receive an automatic confirmation. This is currently known as
"sloppy log checking" by QSL managers...obviously, this problem won't go
away. Even if a high minimum degree-of-confidence is set, if the
resulting mismatched requests aren't carefully reviewed by DX1S, bad QSOs
might still be confirmed and put into the public data base.
DX1S might have a dishonest confirmation manager. DX1S's manager might
make a mistake. Etc., etc. An electronic messaging system doesn't change
human behavior. It would, however, make it possible to reduce
tremendously the amount of effort that goes into QSLing and QSL checking.
If some of the grunt work was removed from the process, it might be that
more time could be spent scrutinizing the mismatched confirmation requests
at both DX1S and the awards organization, making for a higher-quality
system.
73, Ward N0AX
--
CQ-Contest on WWW: http://www.contesting.com/_cq-contest/
Administrative requests: cq-contest-REQUEST@contesting.com
|