vCon T. McCarthy-Howe Internet-Draft VCONIC Intended status: Experimental 1 April 2026 Expires: 3 October 2026 vCon Extension for Morse Code Dialog Encoding draft-howe-vcon-morse-code-extension-00 Abstract This document defines a vCon extension for representing Morse code conversations within the Virtualized Conversation (vCon) container format. Morse code remains an actively used communication medium among amateur radio operators, in historical preservation contexts, and in cultural works. The extension provides standardized encoding for Morse code dialog, including keying timing data, prosign representation, and the Farnsworth timing method. This document also addresses information-theoretic considerations of Morse code's variable-length encoding, its relationship to modern source coding theory, and the privacy implications of preserving historically significant Morse code conversations whose data subjects may be deceased. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://vcon- dev.github.io/draft-howe-vcon-morse-code-extension/draft-howe-vcon- morse-code-extension-latest.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-howe- vcon-morse-code-extension/. Discussion of this document takes place on the vCon Working Group mailing list (mailto:vcon@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/vcon/. Subscribe at https://www.ietf.org/mailman/listinfo/vcon/. Source for this draft and an issue tracker can be found at https://github.com/vcon-dev/draft-howe-vcon-morse-code-extension. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Information-Theoretic Considerations 2. Conventions and Definitions 2.1. Core Terms 3. vCon Morse Code Extension Definition 3.1. Extension Classification 3.2. Extension Registration 3.3. Extension Usage 4. Morse Code Dialog Encoding 4.1. Dialog Object Parameters 4.1.1. Dialog Type 4.1.2. Extension Parameters on Dialog Objects 4.2. Text Encoding Format 4.3. Keying Timing Attachment 4.3.1. Attachment Structure 4.3.2. Element Object Fields 4.3.3. Top-Level Fields 4.4. Morse Code Text Notation Attachment 5. Privacy Considerations for Historical Morse Code Conversations 5.1. Data Subject Status of Deceased Persons 5.2. Fist as Biometric Data 6. Security Considerations 6.1. Integrity of Historical Records 6.2. Keying Timing as Side Channel 6.3. Replay Considerations 7. Interoperability 7.1. Character Set Considerations 7.2. Speed and Timing Compatibility 8. Example vCon 8.1. Amateur Radio Field Day Contact 8.2. Historical Maritime Distress Communication 8.3. Information Efficiency Comparison 9. References 9.1. Normative References 9.2. Informative References Appendix A. IANA Considerations A.1. vCon Extensions Names Registry A.2. Dialog Object Parameter Names Registry A.3. Attachment Type Values A.4. Morse Code Medium Values Registry Appendix B. Full International Morse Code Table B.1. Letters B.2. Digits B.3. Common Prosigns Appendix C. Acknowledgements Author's Address 1. Introduction Morse code, first demonstrated by Samuel Morse and Alfred Vail in the 1830s and 1840s [MORSE1838] [VAIL1844], remains one of the most enduring communication protocols in human history. While it predates the Internet, the telephone, and indeed the vCon specification by approximately 180 years, Morse code continues to serve as an active communication medium in contexts that warrant formal conversation capture and preservation. The American Radio Relay League (ARRL) reports that Continuous Wave (CW) operation, the radio transmission mode that employs Morse code, remains one of the most popular modes during the annual Field Day emergency preparedness exercise [ARRL-FIELD-DAY]. Thousands of licensed amateur radio operators participate in Morse code contacts during this event, generating conversation data that operators may wish to log and preserve in a standardized format. The low bandwidth requirements and noise immunity of Morse code make it a preferred mode when conditions are poor, a property that ensures its continued relevance in emergency communications. Beyond amateur radio, Morse code conversations appear in historical records of significant events. The distress communications from RMS Titanic on April 15, 1912, represent perhaps the most widely known Morse code conversations in history [TITANIC-INQUIRY]. These conversations involved identifiable natural persons as both operators and passengers, raising data protection questions that modern privacy frameworks must address despite the passage of over a century. Morse code conversations also persist in cultural works, including dramatic depictions of telegraph operations during railway communications, maritime distress scenarios, and military operations. When these dramatizations are based on or reproduce actual historical conversations, the same data subject considerations may apply. This document defines a Compatible vCon extension that enables the capture and preservation of Morse code conversations, including the precise keying timing that distinguishes an individual operator's "fist" (their distinctive keying style), the prosigns and abbreviations that form the pragmatic layer of Morse code communication, and metadata about the transmission medium (landline telegraph, radio, or other). 1.1. Information-Theoretic Considerations The variable-length encoding of International Morse Code [ITU-M1677] anticipates by approximately one hundred years the principles of optimal source coding later formalized by Claude Shannon [SHANNON1948] and David Huffman [HUFFMAN1952]. In Morse code, the most frequently occurring letters in English text are assigned shorter symbol sequences: 'E' is encoded as a single dit (.), while 'T' is encoded as a single dah (-). Less frequent letters receive progressively longer encodings, with characters such as 'Q' (--.-) and 'J' (.---) requiring four elements. This design was not accidental. Vail reportedly studied letter frequency by examining a printer's type case at the Morristown, New Jersey newspaper office, counting the quantity of type pieces cast for each letter as a proxy for usage frequency [VAIL1844]. The resulting encoding achieves near-optimal compression for English text, a remarkable empirical result that aligns with the theoretical foundations Shannon would establish a century later. However, implementers MUST be aware that Morse code's information efficiency is optimized for English letter frequencies and degrades significantly for other languages. The Welsh language, for example, makes heavy use of characters and digraphs that receive long Morse encodings. The letter 'W' (.--), a three-element symbol, appears with far greater frequency in Welsh than in English. The Welsh digraph "LL", common in place names such as Llanfairpwllgwyngyll, requires transmission of two four-element sequences (.-.., .-..): eight elements where a frequency-optimized encoding for Welsh might use as few as two. Similarly, the Mi'kmaq language of Eastern Canada contains phonemes and orthographic conventions that map poorly to Morse code's English- optimized encoding. Implementers serving communities that use Mi'kmaq or similar Indigenous languages should be aware that Morse code representation of these languages will exhibit substantially lower information efficiency than for English text. The extreme case may be illustrated by the Nipmuc name for a lake in Webster, Massachusetts: Chargoggagoggmanchauggagoggchaubunagungamaugg. This 45-letter toponym, which translates roughly to "you fish on your side, I fish on my side, nobody fishes in the middle", requires 131 Morse code elements to transmit. An optimal variable-length encoding designed for Nipmuc letter frequencies could represent this name in substantially fewer symbols. Implementers SHOULD NOT assume that Morse code provides efficient encoding for any language other than English, and MAY wish to note the source language in the dialog metadata to enable appropriate interpretation of transmission duration and bandwidth usage. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Core Terms *Morse Code*: A method of encoding text characters as sequences of two signal durations, commonly called dits (short) and dahs (long), standardized in [ITU-M1677]. *Dit*: The fundamental unit of time in Morse code. Represented as "." in text notation. *Dah*: A signal element three times the duration of a dit. Represented as "-" in text notation. *Fist*: The distinctive keying rhythm and timing of an individual Morse code operator. Analogous to a handwriting style, an operator's fist may serve as a biometric identifier. *Prosign*: A procedural signal composed of two or more letters sent without inter-character spacing, used for operational communication. Examples include AR (end of message), SK (end of contact), and SOS (distress). *CW*: Continuous Wave, the radio transmission mode used for Morse code communication. *Farnsworth Timing*: A method of Morse code transmission where individual characters are sent at a higher speed than the overall word rate, with extended inter-character and inter-word gaps. Used for training and accessibility purposes. *WPM*: Words Per Minute, the standard measure of Morse code transmission speed, calibrated using the word "PARIS" as the standard word (50 dit-units per word). *Keying Data*: The precise timing record of dit and dah elements, inter-element gaps, inter-character gaps, and inter-word gaps in a Morse code transmission. 3. vCon Morse Code Extension Definition 3.1. Extension Classification The Morse code extension is a *Compatible Extension* as defined in Section 2.5 of [I-D.draft-ietf-vcon-vcon-core]. This extension: * Introduces Morse code dialog encoding without altering existing vCon semantics * Can be safely ignored by implementations that do not support Morse code processing * Does not require listing in the critical parameter * Maintains backward compatibility with existing vCon implementations 3.2. Extension Registration This document defines the "morse_code" extension token for registration in the vCon Extensions Names Registry: * *Extension Name*: morse_code * *Extension Description*: Morse code dialog encoding with keying timing data, prosign support, and transmission metadata * *Change Controller*: IESG * *Specification Document*: This document 3.3. Extension Usage vCon instances that include Morse code dialog SHOULD include "morse_code" in the extensions array: json { "uuid": "019605ab-3c7d-7000-8000-abcdef012345", "extensions": ["morse_code"], "created_at": "2026-06-28T18:00:00Z", "parties": [...], "dialog": [...], "attachments": [...] } 4. Morse Code Dialog Encoding 4.1. Dialog Object Parameters Morse code conversations are represented as vCon Dialog Objects with the following conventions. 4.1.1. Dialog Type Morse code dialog objects MUST use one of the following type values: * *"text"*: For Morse code content represented as decoded text. This is the RECOMMENDED type for most use cases. * *"recording"*: For audio recordings of Morse code transmissions (e.g., captured CW signals). 4.1.2. Extension Parameters on Dialog Objects The following optional parameters are defined for Dialog Objects containing Morse code: * *morse_wpm*: Number. The transmission speed in Words Per Minute. * *morse_farnsworth_wpm*: Number. The effective Farnsworth speed, if Farnsworth timing is used. When present, individual characters are sent at the rate specified in morse_wpm, with extended spacing yielding the effective rate in morse_farnsworth_wpm. * *morse_medium*: String enum. The physical transmission medium. Values defined by this document are: - "telegraph_landline" - Wired telegraph - "radio_cw" - Radio continuous wave transmission - "radio_other" - Other radio modes (e.g., modulated tone) - "optical" - Visual signaling (e.g., signal lamp, heliograph) - "acoustic" - Sound-based signaling (e.g., horn, whistle) - "other" - Any other medium * *morse_frequency_hz*: Number. The tone frequency in Hertz for CW or side-tone, when applicable. * *morse_source_language*: String. A BCP 47 language tag indicating the source language of the text content. This parameter is RECOMMENDED when the content is in a language other than English, as it provides context for evaluating transmission efficiency (see Section 1.1). 4.2. Text Encoding Format When Morse code dialog is represented as decoded text (dialog type "text"), the body field contains the plain text transcription and the mediatype SHOULD be "text/plain". The decoded text MUST use UTF-8 encoding. Prosigns SHOULD be represented using their conventional meanings (e.g., "SOS" for the distress prosign, "AR" for end of message) and MAY be enclosed in angle brackets to distinguish them from literal text: , , . 4.3. Keying Timing Attachment The precise keying timing of a Morse code transmission MAY be recorded as an attachment. This data preserves the operator's fist characteristics and enables reconstruction of the original transmission. 4.3.1. Attachment Structure Keying timing attachments MUST use: * *type*: "morse_keying" * *encoding*: "json" * *mediatype*: "application/json" The attachment body is a JSON object with the following structure: json { "version": "1.0", "dit_duration_ms": 60, "elements": [ {"type": "dit", "duration_ms": 58, "gap_ms": 62}, {"type": "dah", "duration_ms": 182, "gap_ms": 59}, {"type": "dit", "duration_ms": 61, "gap_ms": 180}, {"type": "dah", "duration_ms": 178, "gap_ms": 421} ] } 4.3.2. Element Object Fields Each element in the elements array MUST contain: * *type*: String enum. One of "dit" or "dah". * *duration_ms*: Number. The duration of the keying element in milliseconds. * *gap_ms*: Number. The duration of the gap following this element in milliseconds. The final element in a transmission MAY omit this field. 4.3.3. Top-Level Fields * *version*: String. MUST be "1.0" for this specification. * *dit_duration_ms*: Number. The nominal dit duration in milliseconds, establishing the reference timing for the transmission. At 20 WPM, this value is 60 milliseconds. 4.4. Morse Code Text Notation Attachment An alternative lightweight encoding for Morse code MAY be stored as an attachment using a text notation format. * *type*: "morse_notation" * *encoding*: "none" * *mediatype*: "text/plain" The body contains the Morse code representation using the following conventions: * . (period) for dit * - (hyphen) for dah * (single space) between characters * / (forward slash) between words * | (pipe) for prosign boundaries (elements sent without inter- character gap) Example: ... --- ...|... / -.-. --.- -.. / -.. . / - .. - .- -. .. -.-. This represents the transmission of the prosign SOS, followed by the text "CQD DE TITANIC". 5. Privacy Considerations for Historical Morse Code Conversations 5.1. Data Subject Status of Deceased Persons Morse code conversations of historical significance frequently involve data subjects who are deceased. The question of whether privacy protections extend to deceased persons varies by jurisdiction and is not settled by any single regulatory framework. Under the GDPR [GDPR], Recital 27 states that the Regulation does not apply to the personal data of deceased persons, but notes that Member States may provide rules regarding the processing of personal data of deceased persons. Several Member States have enacted such provisions. France, for example, provides for digital death rights under the Loi pour une Republique numerique (2016). Italy extends certain data protection rights to deceased persons through the Codice in materia di protezione dei dati personali. When preserving Morse code conversations from historical events such as the RMS Titanic disaster of April 15, 1912, implementers MUST consider: 1. *Passenger and Crew Data*: The Titanic's wireless communications included names of passengers and crew members. While over a century has elapsed, descendants and maritime historical societies maintain active interest in these records. Under the regulatory frameworks of certain jurisdictions, these names may still constitute personal data warranting protection. 2. *Operator Identification*: The Morse code operators involved in the Titanic disaster, including Jack Phillips and Harold Bride of the Titanic and numerous operators at shore stations and on rescue vessels, are identifiable natural persons whose professional communications constitute personal data in the form of their distinctive keying patterns (fist). 3. *Distress Communications*: Messages transmitted under distress conditions, including the CQD and SOS signals from the Titanic, contain information about the life-threatening circumstances of data subjects. This category of information may require elevated privacy protections under vital interests provisions, even when the data subjects are deceased. Implementations that store historical Morse code conversations SHOULD include a lawful basis attachment (as defined in draft-howe-vcon- lawful-basis) documenting the basis for processing, with particular attention to public interest and historical research justifications. 5.2. Fist as Biometric Data An operator's Morse code fist, the distinctive timing pattern of their keying, constitutes biometric data under certain regulatory frameworks. The GDPR classifies biometric data as a special category of personal data (Article 9) when processed for the purpose of uniquely identifying a natural person. The keying timing attachment defined in Section 4.3 preserves fist characteristics with sufficient fidelity to enable operator identification. Implementations that store keying timing data MUST treat this data as potentially biometric and apply appropriate protections. 6. Security Considerations 6.1. Integrity of Historical Records Morse code conversations preserved for historical or archival purposes SHOULD be protected using the vCon signing mechanisms defined in [I-D.draft-ietf-vcon-vcon-core]. Tampering with historical records, such as altering the content of distress transmissions, could have implications for historical scholarship and legal proceedings. 6.2. Keying Timing as Side Channel The keying timing attachment preserves information that may serve as a side channel for operator identification. Even when the text content of a Morse code dialog is redacted, the timing data may enable re-identification of the operator through fist analysis. Implementations that redact Morse code vCons SHOULD consider whether keying timing data must also be redacted to achieve the desired level of anonymization. 6.3. Replay Considerations Morse code transmissions on amateur radio frequencies are inherently broadcast and can be received by any station within range. The vCon container adds provenance metadata to these transmissions. Implementations MUST ensure that the vCon does not falsely attribute a Morse code conversation to parties who were merely receiving a broadcast transmission. 7. Interoperability 7.1. Character Set Considerations International Morse Code [ITU-M1677] defines encodings for the 26 Latin letters (A-Z), the ten digits (0-9), and a small set of punctuation marks and prosigns. Characters outside this set have no standard Morse representation. When encoding text that contains characters without Morse equivalents, implementations SHOULD: 1. Transcribe the text using only characters with defined Morse encodings 2. Note any transliteration or omission in the dialog metadata 3. Record the original text in a separate text dialog object linked via the dialog index Languages that use the Latin alphabet but require additional characters (such as Welsh, which uses the circumflex accent, or Mi'kmaq, which uses the bar and acute accents in its Smith-Francis orthography) present particular challenges. The characters 'ŵ' and 'ê' in Welsh, and 'e'' and 'a'' in Mi'kmaq, have no standard Morse code representation [WELSH-ORTHOGRAPHY] [MIKMAQ-ORTHOGRAPHY]. 7.2. Speed and Timing Compatibility Implementations MUST support dialog objects with any valid WPM value. Common values range from 5 WPM (beginner training speed) to 60 WPM (high-speed contest operation), though values outside this range are permitted. When Farnsworth timing is indicated, implementations MUST interpret the morse_wpm value as the character speed and morse_farnsworth_wpm as the effective overall speed. The character speed MUST be greater than or equal to the Farnsworth speed. 8. Example vCon 8.1. Amateur Radio Field Day Contact This example shows a vCon capturing a Morse code contact during ARRL Field Day: json { "vcon": "0.0.2", "uuid": "019605ab-3c7d- 7000-8000-abcdef012345", "extensions": ["morse_code"], "created_at": "2026-06-28T18:00:00Z", "parties": [ { "name": "K1AUN", "role": "calling_station", "meta": { "callsign": "K1AUN", "location": "Middletown, RI", "arrl_section": "RI", "category": "2A" } }, { "name": "KA1WRL", "role": "responding_station", "meta": { "callsign": "KA1WRL", "location": "Newburgh, NY, "arrl_section": "NY", "category": "1A" } } ], "dialog": [ { "type": "text", "start": "2026-06-28T18:30:00Z", "duration": 45.0, "parties": [0, 1], "mediatype": "text/plain", "encoding": "none", "body": "CQ FD CQ FD DE W1AW W1AW K\nW1AW DE K1TTT K1TTT 1A WMA\nK1TTT DE W1AW R 2A CT 73\nW1AW DE K1TTT R 73 SK", "morse_wpm": 20, "morse_medium": "radio_cw", "morse_frequency_hz": 600, "morse_source_language": "en" } ], "analysis": [], "attachments": [] } 8.2. Historical Maritime Distress Communication This example illustrates how a historically significant Morse code conversation might be preserved. Note the inclusion of privacy- relevant metadata: json { "vcon": "0.0.2", "uuid": "019605ab-4e8f- 7000-8000-191204150000", "extensions": ["morse_code"], "created_at": "1912-04-15T00:45:00Z", "redacted": { "uuid": "019605ab-4e8f- 7000-8000-191204150001", "timestamp": "2026-01-15T00:00:00Z", "reason": "historical_privacy_review" }, "parties": [ { "name": "RMS Titanic (MGY)", "role": "distress_station", "meta": { "callsign": "MGY", "vessel": "RMS Titanic", "position": "41.46N 50.14W" } }, { "name": "RMS Carpathia (MPA)", "role": "responding_station", "meta": { "callsign": "MPA", "vessel": "RMS Carpathia" } } ], "dialog": [ { "type": "text", "start": "1912-04-15T00:45:00Z", "duration": 120.0, "parties": [0, 1], "mediatype": "text/plain", "encoding": "none", "body": " DE MGY MGY POSITION 41.46 N 50.14 W REQUIRE IMMEDIATE ASSISTANCE COME AT ONCE WE HAVE STRUCK ICEBERG SINKING", "morse_wpm": 25, "morse_medium": "radio_cw", "morse_source_language": "en" } ], "analysis": [ { "type": "historical_note", "dialog": 0, "vendor": "maritime_historical_society", "encoding": "json", "body": { "note": "This vCon represents a reconstruction of wireless telegraphy transmissions from the RMS Titanic on the night of April 14-15, 1912. The original transmissions were made by wireless operators Jack Phillips and Harold Bride. Content is derived from testimony given at the British Wreck Commissioner's Inquiry.", "source": "British Wreck Commissioner's Inquiry, 1912", "data_subject_status": "deceased", "historical_significance": "The Titanic disaster led directly to the International Convention for the Safety of Life at Sea (SOLAS) and mandatory wireless watch requirements for passenger vessels." } } ], "attachments": [] } 8.3. Information Efficiency Comparison This non-normative example illustrates the encoding efficiency disparity discussed in Section 1.1 by showing the Morse code element count for equivalent-length words in different languages: +========+======================+============+========+===========+ |Language| Word | Characters |Morse | Elements/ | | | | |Elements| Char | +========+======================+============+========+===========+ |English | "the" | 3 |6 | 2.00 | +--------+----------------------+------------+--------+-----------+ |English | "station" | 7 |14 | 2.00 | +--------+----------------------+------------+--------+-----------+ |Welsh | "llanfair" | 8 |23 | 2.88 | +--------+----------------------+------------+--------+-----------+ |Welsh | "gwyllwch" | 8 |29 | 3.63 | +--------+----------------------+------------+--------+-----------+ |Mi'kmaq | "kiju'lkwejk" | 10 |30 | 3.00 | +--------+----------------------+------------+--------+-----------+ |Nipmuc | "chaubunagungamaugg" | 18 |48 | 2.67 | +--------+----------------------+------------+--------+-----------+ Table 1 The table demonstrates that Morse code achieves its best efficiency for common English words, where the Shannon-optimal properties of the encoding are most apparent. For Welsh and Mi'kmaq text, the encoding overhead increases measurably, confirming the theoretical prediction that a code optimized for one language's symbol frequencies will be suboptimal for another. 9. References 9.1. Normative References [I-D.draft-ietf-vcon-vcon-core] Petrie, D. G., "The JSON format for vCon - Conversation Data Container", Work in Progress, Internet-Draft, draft- ietf-vcon-vcon-core-02, January 2026, . [ITU-M1677] International Telecommunication Union, "International Morse code", 2009, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [ARRL-FIELD-DAY] American Radio Relay League, "ARRL Field Day", 2025, . [GDPR] European Union, "General Data Protection Regulation", 2018, . [HUFFMAN1952] Huffman, D. A., "A Method for the Construction of Minimum- Redundancy Codes", Proceedings of the IRE 40(9):1098-1101, September 1952. [MIKMAQ-ORTHOGRAPHY] Mi'kmaq Online, "Mi'kmaq Hieroglyphic Writing and Orthography", 2023, . [MORSE1838] Morse, S. F. B., "Improvement in the mode of communicating information by signals by the application of electro- magnetism", US Patent 1,647, 1840. [SHANNON1948] Shannon, C. E., "A Mathematical Theory of Communication", July 1948, . [TITANIC-INQUIRY] British Board of Trade, "British Wreck Commissioner's Inquiry into the Loss of the Titanic", 1912, . [VAIL1844] Silverman, K., "Alfred Vail and the Invention of the Morse Telegraph Code", 2003. [WELSH-ORTHOGRAPHY] Welsh Language Commissioner, "Welsh Orthography and the Frequency of Welsh Letters", 2020, . Appendix A. IANA Considerations A.1. vCon Extensions Names Registry This document requests IANA to register the following extension in the vCon Extensions Names Registry established by [I-D.draft-ietf-vcon-vcon-core]: * *Extension Name*: morse_code * *Extension Description*: Morse code dialog encoding with keying timing data, prosign support, and transmission metadata for the vCon conversation container * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX A.2. Dialog Object Parameter Names Registry This document requests IANA to register the following parameters in the Dialog Object Parameter Names Registry: +=======================+==============+==========+===============+ | Parameter Name | Parameter |Change | Specification | | | Description |Controller| Document(s) | +=======================+==============+==========+===============+ | morse_wpm | Morse code |IESG | RFC XXXX, | | | transmission | | Section 4.1 | | | speed in WPM | | | +-----------------------+--------------+----------+---------------+ | morse_farnsworth_wpm | Farnsworth |IESG | RFC XXXX, | | | effective | | Section 4.1 | | | speed in WPM | | | +-----------------------+--------------+----------+---------------+ | morse_medium | Physical |IESG | RFC XXXX, | | | transmission | | Section 4.1 | | | medium | | | +-----------------------+--------------+----------+---------------+ | morse_frequency_hz | CW tone |IESG | RFC XXXX, | | | frequency in | | Section 4.1 | | | Hertz | | | +-----------------------+--------------+----------+---------------+ | morse_source_language | BCP 47 |IESG | RFC XXXX, | | | language tag | | Section 4.1 | | | for source | | | | | text | | | +-----------------------+--------------+----------+---------------+ Table 2 A.3. Attachment Type Values This document defines the following attachment type values: +================+=========================================+ | Type Value | Description | +================+=========================================+ | morse_keying | Morse code keying timing data | +----------------+-----------------------------------------+ | morse_notation | Morse code text notation representation | +----------------+-----------------------------------------+ Table 3 A.4. Morse Code Medium Values Registry This document requests IANA to establish a new registry for Morse code medium values with the following initial registrations: +====================+====================================+ | Medium Value | Description | +====================+====================================+ | telegraph_landline | Wired telegraph | +--------------------+------------------------------------+ | radio_cw | Radio continuous wave transmission | +--------------------+------------------------------------+ | radio_other | Other radio modes | +--------------------+------------------------------------+ | optical | Visual signaling | +--------------------+------------------------------------+ | acoustic | Sound-based signaling | +--------------------+------------------------------------+ | other | Any other medium | +--------------------+------------------------------------+ Table 4 Registration Template: *Medium Value*: The string value used as the medium identifier *Description*: Brief description of the transmission medium *Change Controller*: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. *Specification Document(s)*: Reference to defining documents with URIs where available Appendix B. Full International Morse Code Table For reference, the complete International Morse Code encoding as standardized in [ITU-M1677]: B.1. Letters +===========+=======+==========+ | Character | Morse | Elements | +===========+=======+==========+ | A | .- | 2 | +-----------+-------+----------+ | B | -... | 4 | +-----------+-------+----------+ | C | -.-. | 4 | +-----------+-------+----------+ | D | -.. | 3 | +-----------+-------+----------+ | E | . | 1 | +-----------+-------+----------+ | F | ..-. | 4 | +-----------+-------+----------+ | G | --. | 3 | +-----------+-------+----------+ | H | .... | 4 | +-----------+-------+----------+ | I | .. | 2 | +-----------+-------+----------+ | J | .--- | 4 | +-----------+-------+----------+ | K | -.- | 3 | +-----------+-------+----------+ | L | .-.. | 4 | +-----------+-------+----------+ | M | -- | 2 | +-----------+-------+----------+ | N | -. | 2 | +-----------+-------+----------+ | O | --- | 3 | +-----------+-------+----------+ | P | .--. | 4 | +-----------+-------+----------+ | Q | --.- | 4 | +-----------+-------+----------+ | R | .-. | 3 | +-----------+-------+----------+ | S | ... | 3 | +-----------+-------+----------+ | T | - | 1 | +-----------+-------+----------+ | U | ..- | 3 | +-----------+-------+----------+ | V | ...- | 4 | +-----------+-------+----------+ | W | .-- | 3 | +-----------+-------+----------+ | X | -..- | 4 | +-----------+-------+----------+ | Y | -.-- | 4 | +-----------+-------+----------+ | Z | --.. | 4 | +-----------+-------+----------+ Table 5 B.2. Digits +===========+=======+==========+ | Character | Morse | Elements | +===========+=======+==========+ | 0 | ----- | 5 | +-----------+-------+----------+ | 1 | .---- | 5 | +-----------+-------+----------+ | 2 | ..--- | 5 | +-----------+-------+----------+ | 3 | ...-- | 5 | +-----------+-------+----------+ | 4 | ....- | 5 | +-----------+-------+----------+ | 5 | ..... | 5 | +-----------+-------+----------+ | 6 | -.... | 5 | +-----------+-------+----------+ | 7 | --... | 5 | +-----------+-------+----------+ | 8 | ---.. | 5 | +-----------+-------+----------+ | 9 | ----. | 5 | +-----------+-------+----------+ Table 6 B.3. Common Prosigns +=========+===========+==============================+ | Prosign | Morse | Meaning | +=========+===========+==============================+ | AR | .-.-. | End of message | +---------+-----------+------------------------------+ | AS | .-... | Wait | +---------+-----------+------------------------------+ | BT | -...- | Break / New paragraph | +---------+-----------+------------------------------+ | CL | -.-..-.. | Closing station | +---------+-----------+------------------------------+ | SK | ...-.- | End of contact | +---------+-----------+------------------------------+ | SOS | ...---... | Distress | +---------+-----------+------------------------------+ | KN | -.--. | Go ahead, named station only | +---------+-----------+------------------------------+ Table 7 Appendix C. Acknowledgements * The amateur radio community, whose continued use of Morse code provides the primary motivation for this extension. Their dedication to preserving CW operation ensures that this communication mode remains vibrant nearly two centuries after its invention. In reality, no nerds are nerdier than you. * The memory of Jack Phillips, senior wireless operator aboard RMS Titanic, who remained at his post transmitting distress signals until the ship's power failed, and of all those who perished in the disaster. Not only do their communications serve as a solemn reminder that conversation data, however encoded, records human experience, but emphasizes and confirms that in conversations our lives, opinions and very existence become real. * Alfred Vail, whose underappreciated contribution to the development of the Morse code encoding deserves recognition. His empirical study of English letter frequencies at the Morristown newspaper office constituted an early and remarkably effective exercise in source coding optimization. When people claim that others over complicate a problem, I think of both Alfred Vail and Évariste Galois, and think those people might have a point. * Claude Shannon, whose formalization of information theory provided the mathematical framework for understanding why Morse code works as well as it does for English, and why it works less well for Welsh. In a chess match between Shannon and Einstein, my bets land on Shannon; I am assured he would be naturally more efficient in his movements. * K1AUN ("K1 Awful Ugly Nut"), for the phone patch in the car, the dipole in the backyard, the key strapped to your leg as we drove over the Newport bridge, marrying my mother, and for embodying a decent and friendly man - Thank you, Dad. And to K1AUO, who took the license examination at the same time, presumably on a dare, and never transmitted a single dit - but earned the callsign nonetheless. Best hacker I ever knew. Thank you, Mom. 88, your son, KA1JYL. -.- .---- .- ..- -. --..-- ..-. --- .-. - .... . .--. .... --- -. . .--. .- - -.-. .... .. -. - .... . -.-. .- .-. --..-- ..-. --- .-. - .... . -.. .. .--. --- .-.. . .. -. - .... . -... .- -.-. -.- -.-- .- .-. -.. --..-- ..-. --- .-. -- .- .-. .-. -.-- .. -. --. -- -.-- -- --- - .... . .-. --..-- -.- .---- .- ..- --- --..-- .- -. -.. ..-. --- .-. . -- -... --- -.. -.-- .. -. --. - .... . ..-. .-. .. . -. -.. .-.. -.-- -- .- -. --..-- - .... .- -. -.- -.-- --- ..- -.. .- -.. .-.-.- --... ---.. --..-- ---.. ---.. .-.-.- -.- .- .---- .--- -.-- .-.. .-.-.-. Author's Address Thomas McCarthy-Howe VCONIC Email: ghostofbasho@gmail.com