Receipt Confirmation Policy (proposed)
by Don Felgenhauer K7BFL
May 27, 2006
revised October 8, 2014
Every formal written message initiated by a ARES/RACES station
should include the following statement at the end of the message:
"Receipt confirmation of this message is requested".
Discussion:
The problem of "lost messages" has received recent attention because
of increased "radio email" activity via the Winlink system.
- Was the message composed, but never sent?
- Was the email address/telephone number/address
correct?
- Did the message get lost in the internet infrastructure?
- Did the message get lost during a manual relay?
- Is the radio/computer/TNC working at the receiving
end?
- Was the message Delivered, but no one read
it?
- Did a Relay Station make an error in relaying
information?
- etc.....
This problem is not new. It has existed for
years with NTS radiograms. Most of us deal with it daily
through our communications via email. We deal with it when we leave
a voice message on an "answering machine" or "Voice Mail".
We deal with it when we send a letter to someone via the postal service.
If one assumes that ALL written ARES/RACES messages are "important"
(they must have a high value, otherwise they would not have been created!),
then it is IMPERATIVE that we create a timely feedback mechanism to
notify the original author of the message that yes, the message has been
READ by the intended recipient. This feedback information
is necessary, independent of the various systems (radiogram, email, Winlink,
NTS, peer-to-peer, etc.) and modes (digital, voice, telephone, packet,
pactor, CW, etc.) that were used to transfer the message.
The "receipt conformation" message need not be written, but it MUST
occur. It is our only salvation from the "Black Hole
of Technology". Voice Command Nets, in support of the written
message processes, should be considered as a method to accomplish Receipt
Confirmation.
If the message is not addressed DIRECTLY to the email address of the
intended recipient, then we have an associated "problem" with which to
deal. Example: A email from Supply Person Jones,
located at Regional Headquarters, is sent to Incident Commander Smith
at Fire Camp Alpha, using an email address of VE7ABC@winlink.org.
The ARES/RACES operator at VE7ABC should send a "Receipt Confirmation" message
ONLY AFTER the message has been Delivered to Commander Smith, not when it
arrived in the email "In Box" of VE7ABC.
NTS Radiogram procedures include a option for "Handling Instructions".
These include:
- HXC--Report date and time of delivery (TOD)
to originating station.
- HXD--Report to originating station the identity
of station from which received, plus date and time. Report identity of
station to which relayed, plus date and time, or if delivered report date,
time and method of delivery.
- HXE--Delivering station get reply from addressee,
originate message back.
Assuming that "plain language" is a more reliable way to communicate
than using "codes"; it would be best if the "HX---" codes were not substituted
for the words of the policy. Handling Instructions are ok to
use, but the words "Please confirm receipt of this message" [or equivalent
words] should also be included in the body of the message.
The sending party needs to determine what is an appropriate amount
of time to wait for a Receipt Confirmation message before re-sending the
message via a different method, or changing the address, etc..
If the Receipt Confirmation process is burdensome to particular stations
or operating positions, the task might be better handled by other supporting
stations with more manpower and/or higher speed communications facilities.
This policy would apply to ALL written messages: radiograms, emails,
packet BBS messages, etc.