A Few Protocol Curiosities from ARES/RACES Message Passing
While learning the Santa Clara County ARES/RACES voice message handling procedures, I was struck by how thoughtfully designed they are. The procedures clearly reflect a lot of operational experience and careful thinking about how to move structured information reliably over voice radio.
That’s not an easy problem. Unlike written or digital communication, voice traffic has to contend with noise, misunderstandings, and operators who may not have worked together before. The procedures solve this by introducing a carefully defined vocabulary of **prowords** and conventions that make message structure predictable and unambiguous.
The procedures themselves are documented here:
https://www.scc-ares-races.org/operations/voice/Message_Handling_Procedures_v20250812.pdf
While practicing message passing and reading through the document, a few interesting protocol-design thoughts occurred to me. None of these observations are criticisms of the procedures themselves—just reflections from the perspective of someone who spends a lot of time thinking about communication protocols and data formats.
In many ways, ARES/RACES voice traffic handling looks surprisingly similar to a **human-operated data protocol**.
---
Prowords and Literal Text
One of the key ideas in the procedures is that **prowords are control signals**, not part of the message text. Words like BREAK, FIGURES, NEW LINE, and others help structure the transmission and guide the receiving operator.
Because of this, prowords themselves are **not written down** as part of the message.
That works well most of the time, but it creates an interesting edge case: what happens if a proword appears as normal text inside the message?
For example:
> “The sales figures look strong this quarter.”
On a net, the word **FIGURES** could be interpreted as the proword that introduces numbers rather than the literal word “figures.”
According to the procedure document, the **prescribed way to handle this** is to use the **I SPELL** proword:
> “The sales figures I SPELL FOXTROT INDIA GOLF UNIFORM ROMEO ECHO SIERRA look strong this quarter.”
This works perfectly. The receiving operator now knows to write down the word rather than interpret it as a procedural signal.
But it also led me to an interesting observation: in this situation, **I SPELL isn’t really about spelling**.
The receiver almost certainly already knows how to spell “figures.” The purpose here is actually to say:
> “Treat the previous word as literal text, not as a proword.”
---
An “Escape Sequence” for Voice Traffic
If this problem sounds familiar, it’s because the same thing appears in many data protocols.
In programming languages and network protocols, control characters often need to be **escaped** when they appear as normal data. For example:
quotation marks in strings
markup characters in HTML
control bytes in binary protocols
Those systems usually introduce an **escape character** to signal that the next token should be interpreted literally.
That made me wonder whether voice procedure could theoretically have something similar.
For example, imagine a hypothetical proword like **ESCAPE**:
> “The sales ESCAPE figures look strong this quarter.”
This would indicate that the following word should be treated as literal text rather than as a procedural keyword.
To be clear, I’m not suggesting the existing procedures need such a feature—the current **I SPELL** approach works well and is clearly defined in the procedure document. But it was interesting to notice how naturally the idea of an escape mechanism arises once you start thinking of voice message passing as a structured protocol.
---
The Symbol Vocabulary
Another interesting design choice appears in the procedures’ handling of symbols.
The document includes a standardized list of spoken names for common symbols. Restricting the vocabulary in this way makes a lot of sense: it ensures that every operator on the net interprets symbols the same way.
But the rule leads to an interesting edge case.
If a message contains a symbol **not on the approved list**, even if the sender recognizes it, the correct procedure is to say:
> **UNKNOWN SYMBOL**
and leave a blank space in the written message.
For example, imagine a message that includes a currency symbol such as **₹ (Indian Rupee)** or **£ (British Pound)**.
Written message:
> The total cost is ₹50.
If the symbol is not part of the standardized vocabulary, the spoken transmission would be something like:
> “The total cost is UNKNOWN SYMBOL FIGURES five zero.”
Or:
Written message:
> The replacement part costs £75.
Spoken transmission:
> “The replacement part costs UNKNOWN SYMBOL FIGURES seven five.”
In both cases, the receiving operator would write the number but leave a blank space where the symbol appeared.
From a protocol-design perspective, this is an interesting tradeoff. The rule intentionally prioritizes **shared vocabulary and consistency** over transmitting information that might not be universally recognized.
That makes a lot of sense for emergency communications, where clarity and interoperability are more important than perfect fidelity. Still, it creates the occasional moment where the operator may know exactly what the symbol is but still can’t transmit it within the standardized vocabulary.
---
FIGURE vs FIGURES (and SYMBOL vs SYMBOLS)
Another small detail that caught my attention while learning the procedures was the distinction between **singular and plural prowords**.
For example, the procedures differentiate between **FIGURE** and **FIGURES** depending on how many digits follow. The same distinction also appears with **SYMBOL** and **SYMBOLS**.
This works perfectly well, but it made me wonder whether always using the plural forms—**FIGURES** and **SYMBOLS**—might simplify the grammar slightly.
Many structured communication systems intentionally avoid singular/plural distinctions for exactly that reason.
Of course, the current rules are clear and well-defined, and operators quickly learn them in practice. It was simply one of those small protocol-design curiosities that stood out while learning the system.
---
Voice Traffic as a Protocol
Stepping back, what fascinated me most while learning these procedures is how closely they resemble the design of modern communication protocols.
The system includes:
**Control signals** (prowords)
**Structured message fields**
**Standardized vocabularies**
**Rules for resolving ambiguity**
These are exactly the same design challenges that appear in digital communication systems.
Long before TCP/IP, JSON, or other structured data formats, radio operators were already solving the problem of reliably transmitting structured information using nothing but voice.
And in many cases, they solved it remarkably well.
---
A Slightly Absurd Thought Experiment
Once you start thinking about message passing in protocol terms, it’s hard not to wonder how far the idea could go.
For example, could we theoretically transmit an image over voice traffic?
Something like:
> BITMAP IMAGE
> PIXEL #FF9E3A
> PIXEL #00FEAB
> NEW LINE
> PIXEL …
Or perhaps raw binary data:
> BINARY DATA OCTET STREAM
> ZERO ONE ONE ZERO ZERO ONE ZERO…
Or if we want to be slightly more efficient:
> HEX DATA OCTET STREAM
> FF EF D1 04
At that point we’ve basically reinvented packet switching, but very inefficiently.
But it highlights something interesting: voice traffic handling is already a structured data protocol — just one implemented entirely by humans with radios and notebooks.
