The Future of Electronic QSL Services



In spite of initial acceptance of the concept on small scale individual web sites, such as http://www.eQSL.cc, the electronic QSL (el.QSL) service has several major problems to overcome before it becomes a large scale service.

Directory Service

The directory of log servers would be the first place to start. We already have dozens of different log servers, and it is not easy to keep track of those. Every day new ones are coming on board with more and more logs to be searched.

The hosting of someone's log in electronic form is a necessary, but not sufficient condition for success of a universal el.QSL service.

Uploading and Storage

The prerequisite for any el.QSL service is that individuals can upload, and maintain their data (logs) at their convenience. It is not a good idea to host the same log on several sites, unless there is a strong demand for mirroring.

Serious log server owners will face extra expenses for maintaining the service and keeping backups of logs for other people. Would the 'server farm' provide secure backup, and offer its own inexpensive 'rent-a-disk-space' alternative to dedicated el.QSL servers?

Currently storage space for logs is free. However, with a large number of users, we will be facing charges for having logs on-line. This will discourage people from keeping logs available on-line for an extended period of time, an essential requirement for a universal el.QSL service.

Provision of an el.QSL service, without a viable business case for the host provider, will not last long.

The el.QSL Service

We still do not have a proper definition of el.QSL Service. Current versions are just electronic versions of paper cards, invented in 1920, but there is much more that could be done with new technologies that are available today.

The essential information on the normal paper QSL card is not more than 20 characters long. Should we consider enhancements to the essential information such as: copy of the license, photos of the operator or his/her shack, multimedia presentation of the antenna and indication of its azimuth, audio clip of the QSO, how many time the station has been called before the QSO completed, or propagation details (indices) at the moment of the QSO - the last because it can be used for statistical research?

Do not forget SWLs. Should they even listen the air-waves, or just search the logs, and help themselves? Alternatively, should we consider the SWL report of two way communications, equally reliable, as the report of any of the two parties involved? After all, SWLs will undergo the same authentication procedure as anyone else.

The end users should be able to find a particular log server, or to traverse a whole series of log servers for their el.QSL record. Alternatively, the system might allow the user to just ask his local el.QSL server for the el.QSL record, while the service provider would traverse all the remote log servers.

Some operators have several callsigns. Should one retrieval be able to find all el.QSL records waiting to be retrieved for all call signs of the end user?

Should el.QSL servers notify end users of the new arrival of el.QSL records or simply wait for the end-user's explicit request?

What happens after the retrieval of an el.QSL card? Is the QSO entry deleted? Is notification sent to the log owner? What happens with the el.QSL records or even entire logs that are never accessed?

What is the format of retrieval: just printing, or retrieving .pdf or .jpeg or any other (not so easy to modify) format?

What about the enhancements to a standard QSL card, that we mentioned before, and that may require .mpeg or .wav files?

With a small number of el.QSL servers it is easy to do on-line printing. However, with a large number of servers, log server traversing, downloading for off-line printing (or just local storage) will be the basic mode of operation.

We can also consider the other extreme. What if s/w applications simply compare the log entries (e.g. essential information), without issuing any QSL card at all? From awards managers' perpective this is OK, but may have impact on our QSL card collecting habits.

Miscellaneous

Authentication and record format, are technological issues and will be solved. There are two identification requirements - one for retrieving the el.QSL record, and one for uploading the log.

Should log data be made available to anyone, or just to a person that is adequately authenticated? It would be desirable for the logs to be accessed by those who are not necessarily interested in getting their own el.QSL records (for example award managers, amateurs monitoring the progress of a DXpedition, or even people doing research).

It would be desirable to have one or more application programs, so that 'raw' data would never need to be accessed and interpreted. The el.QSL records would be retrieved only through such an application. Development of those applications could be the major differentiator between a variety of el.QSL service providers.

Paper QSL cards will coexist for some time with any el.QSL system. This will be because not all individuals and organizations will be on the internet in the foreseeable future, and their needs should continue to be met. We may consider a number of combinations between the two QSL systems in order to minimize the operating costs. With the skyrocketing prices of postage, el.QSL, if economically justified and properly designed, is the clear alternative.

An attractive approach would be to allow printing of 'acceptable' cards from El.QSL records only by 'authorized' organizations/individuals. Should organization ever get involved, or should leave this busines to adequately equipped individuals? Would award managers credit those printed cards, once they start crediting the el.QSL version? Would a paper QSL card override the el.QSL card or the other way around?

Those are just some of the questions that need answers before el.QSL becomes a widely used commodity service.

References:

zs6ez.za.org

trustedQSL.org

Go back to top

Last Updated on Apr.30.2001
By Nenad VE3EXY
Email: ve3exy@rac.ca