The HONK Protocol: Word-Counting over TCP with Honk-Based Responses and Optional Obfuscation

The HONK Protocol: Word-Counting over TCP with Honk-Based Responses and Optional Obfuscation Independent

me@elaine.is

Applications and Real-Time honk word counting UTF-8 text processing obfuscation This document defines the HONK protocol, a simple application-layer protocol operating over TCP. A HONK client submits a stream of UTF-8 encoded text terminated by a CRLF sequence, and the HONK server responds with a sequence of HONK tokens. The token count equals twice the number of whitespace-delimited words detected in the input. If no words are detected, the server responds with exactly three HONK tokens. The protocol includes an optional Privacy Mode in which message content is obfuscated using single-byte XOR with the fixed key value 0x48 (the ASCII code point for the letter H). This document requests that IANA assign TCP port 24565 to the HONK service. This document is an individual submission. It is NOT an April Fools Day publication. The author requests serious technical consideration from the IETF community.

Introduction Many application-layer protocols accept text from a client and return structured feedback. The HONK protocol defines one such exchange: a client submits a line of UTF-8 text, and the server acknowledges the submission by emitting a number of HONK tokens proportional to the word count of that line. The design goals of the HONK protocol are:

Simplicity: A conformant implementation requires only a TCP socket, a UTF-8 decoder, a whitespace tokenizer, and the ability to write a line of ASCII text.
Clarity of signal: The HONK response is distinctive and human-readable. An operator monitoring a session can immediately confirm the server is functioning.
Interoperability: TCP transport and UTF-8 encoding make the protocol accessible to any platform capable of opening a TCP connection.
Optional obfuscation: Privacy Mode reduces the legibility of HONK traffic to casual observers. Privacy Mode is explicitly NOT a security mechanism and does not provide cryptographic confidentiality; see .

Practical applications include network-accessible word-count feedback services, smoke-test endpoints in text processing pipelines, and educational demonstrations of application-layer protocol design and implementation.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here.

HONK token: The four-character ASCII string "HONK" (0x48 0x4F 0x4E 0x4B).
Request: A single line of UTF-8 encoded text submitted by a HONK client, terminated by CRLF. In Privacy Mode, the line content is XOR-obfuscated before transmission.
Response: A server-generated line of one or more HONK tokens separated by SP and terminated by CRLF. In Privacy Mode, the line content is XOR-obfuscated before transmission.
Word: A maximal non-empty sequence of Unicode code points none of which have the Unicode property White_Space=Yes per Unicode Standard Annex 44. The CRLF terminator is not part of the Request body and MUST NOT be counted.
Honk count (N): The number of HONK tokens in a Response, computed per .
CRLF: The two-octet sequence CR LF (0x0D 0x0A). CRLF is the line terminator for all HONK messages and is never obfuscated, even in Privacy Mode.
Privacy Mode: An optional session mode negotiated at connection open. Request and Response content bytes are XOR'd with the key K = 0x48. Privacy Mode does not provide cryptographic confidentiality. See .
Obfuscation key (K): The fixed single-octet value 0x48, the ASCII code point for the letter H. Chosen for its mnemonic association with the word HONK.

Protocol Overview The HONK protocol uses a request-response model over a persistent TCP connection. Two session modes exist: Standard Mode and Privacy Mode. The mode is set at connection open and applies for the full lifetime of that connection.

Standard Mode

Client establishes a TCP connection to server port 24565.
Client transmits a Request: UTF-8 text followed by CRLF.
Server counts words, computes N, and sends a Response of N HONK tokens.
Steps 2 and 3 MAY repeat. Either party MAY close the connection at any time.

Privacy Mode The client sends "HONK PRIV\r\n" as the very first transmission. The server acknowledges with "HONK PRIV\r\n". Both lines are cleartext. All subsequent Request and Response content on that connection is XOR-obfuscated with K = 0x48. CRLF terminators are never obfuscated.

Privacy Mode Exchange | |<-- "HONK PRIV\r\n" (cleartext) --------- | | (Privacy Mode now active) | | | |--- [XOR("hello world", K=0x48)]\r\n ---> | |<-- [XOR("HONK HONK HONK HONK",K)]\r\n - | | | |--- TCP FIN ----------------------------> | |<-- TCP FIN-ACK ------------------------- | ]]> Privacy Mode MUST be negotiated before any Request is sent. A server receiving any line other than "HONK PRIV\r\n" as the first line operates in Standard Mode for the lifetime of that connection.

Message Format

Request Format A Request is a UTF-8 encoded line terminated by CRLF. The body (everything before the CRLF) MUST be valid UTF-8 per . The CRLF is not part of the body and MUST NOT be included in word counting. In Privacy Mode, the body bytes are obfuscated per before transmission; the CRLF is always transmitted as cleartext. The following grammar uses the ABNF notation defined in : Implementations SHOULD impose a maximum request body length. The RECOMMENDED maximum is 65535 octets excluding the CRLF. A server MAY close the connection if this limit is exceeded. A server receiving invalid UTF-8 (after de-obfuscating in Privacy Mode) MUST close the connection without a Response.

Response Format A Response is N HONK tokens separated by SP and terminated by CRLF, where N is computed per . In Privacy Mode, the response content bytes are obfuscated per before transmission.

Word Counting

Interpret the request body as Unicode code points in UTF-8.
Partition the sequence into runs of whitespace and non-whitespace, where a code point is whitespace if and only if it has Unicode property White_Space=Yes per Unicode Standard Annex 44.
Each maximal non-empty run of non-whitespace code points is one word.
The word count W is the total number of such runs.

A body consisting entirely of whitespace has W = 0 and MUST receive the default response of three HONK tokens.

Honk Count Computation Let W be the word count. The honk count N is:

If W is greater than zero: N = 2 * W
If W equals zero: N = 3

Implementations SHOULD impose a maximum N. The RECOMMENDED maximum is 65535. A server MAY cap N at its configured maximum without signaling an error to the client.

Privacy Mode

Purpose and Limitations Privacy Mode provides lightweight obfuscation of HONK message content. It is designed solely to reduce readability of HONK sessions to casual, non-targeted observers such as automated log scanners not specifically looking for HONK traffic. Privacy Mode does NOT provide cryptographic confidentiality, integrity, or authentication. The key K = 0x48 is fixed and publicly specified in this document; any party with access to this specification can immediately de-obfuscate all Privacy Mode traffic. Furthermore, because HONK Responses consist entirely of predictable tokens, Privacy Mode is trivially broken by a known-plaintext attack using a single observed Response. Operators requiring genuine confidentiality MUST use TLS or an equivalent mechanism.

Mode Negotiation A client wishing to use Privacy Mode MUST send the following as the very first transmission on the connection: A server receiving "HONK PRIV\r\n" as the first line MUST respond with: Both lines are cleartext. After the server sends "HONK PRIV\r\n", Privacy Mode is active for the remainder of that connection. A client MUST NOT send "HONK PRIV\r\n" after sending any Request on the same connection.

Obfuscation Transform Every octet of a Request or Response body is XOR'd with K = 0x48 before transmission. The transform is its own inverse: applying it twice recovers the original content. Let B = (b_0, b_1, ..., b_{n-1}) be the body octets. The obfuscated sequence B' is defined as: The CRLF terminator is appended to B' after the transform and is never obfuscated, preserving line framing regardless of body content. The following table shows the obfuscated form of selected characters for implementor reference: XOR Transform Reference (K = 0x48)

Cleartext	Hex	Obfuscated hex	Obfuscated char
H	0x48	0x00	NUL
O	0x4F	0x07	BEL
N	0x4E	0x06	ACK
K	0x4B	0x03	ETX
SP	0x20	0x68	h

Note that the obfuscated form of H is the NUL byte (0x00). Implementations MUST NOT treat NUL bytes received in Privacy Mode as string terminators or error conditions.

Session Management A session begins when a client establishes a TCP connection. The client MAY send multiple sequential Requests after any Privacy Mode negotiation. The server MUST process each Request and send the corresponding Response before processing the next. Pipelining is NOT RECOMMENDED. The server SHOULD implement an idle connection timeout. A RECOMMENDED default is 30 seconds from the time the last Response was sent. Either party MAY close the connection at any time. The server SHOULD transmit any pending Response before initiating a close.

Implementation Considerations

Unicode Whitespace Handling Implementations MUST use the Unicode White_Space property for word boundary detection and MUST NOT limit whitespace detection to ASCII characters only. Implementors SHOULD verify that the chosen library function covers the full Unicode White_Space property set.

Line Ending Handling CRLF is the canonical line terminator. Server implementations MAY additionally accept a bare LF for compatibility with clients that do not emit CR. In Privacy Mode the bare LF MAY also be accepted, since CRLF bytes are never obfuscated.

NUL Bytes in Privacy Mode As shown in , the obfuscated form of the letter H is the NUL byte 0x00. Because every HONK token begins with H, the obfuscated form of every Response token begins with NUL. Implementations MUST NOT treat NUL bytes in Privacy Mode content as string terminators. Implementations using null-terminated string APIs MUST account for this explicitly.

Concurrency A HONK server MUST handle multiple simultaneous client connections. Implementations SHOULD use concurrent I/O mechanisms appropriate to their runtime environment.

Security Considerations

Privacy Mode Provides No Cryptographic Security Privacy Mode MUST NOT be construed as providing cryptographic confidentiality, authentication, or integrity. The key K = 0x48 is fixed and publicly documented in this specification. Any observer with access to this document can de-obfuscate all Privacy Mode traffic immediately. Privacy Mode is trivially broken by a known-plaintext attack using a single observed Response. Operators requiring genuine confidentiality MUST use TLS or an equivalent cryptographically secure transport.

Resource Exhaustion Servers MUST implement a maximum request body length per and a maximum honk count N per . Servers SHOULD limit concurrent connections and MUST implement idle timeouts per .

UTF-8 Input Validation Servers MUST validate that the request body is well-formed UTF-8 after de-obfuscating in Privacy Mode. Servers receiving invalid UTF-8 MUST close the connection without sending a Response.

Network Exposure The HONK protocol provides no authentication or authorization. Operators deploying a HONK server on a publicly accessible interface SHOULD restrict access using network-layer controls. Deployment on a public interface without access controls is NOT RECOMMENDED.

IANA Considerations IANA is requested to assign the following entry in the Service Name and Transport Protocol Port Number Registry : IANA Port Assignment Request

Field	Value
Service Name	honk
Port Number	24565
Transport Protocol	TCP
Description	HONK: word-counting service with honk-based responses
Assignee	G00se (me@elaine.is)
Contact	G00se (me@elaine.is)
Reference	[This document]

At the time of this writing, port 24565 does not appear in the IANA Service Name and Transport Protocol Port Number Registry as an assigned or reserved value. UDP port 24565 is not requested at this time. Per , IANA SHOULD mark UDP port 24565 as Reserved when assigning TCP port 24565.

References Normative References Informative References

Go Reference Implementation (Informative) The following is the reference implementation of the HONK protocol, providing both server and client in a single Go source file. It requires Go 1.21 or later. The compiled binary is named "honk". Usage: When invoked as "honk send", text may be supplied as command-line arguments or read line-by-line from standard input if no arguments are given. 0 { send(strings.Join(rest, " ")) return } stdin := bufio.NewScanner(os.Stdin) for stdin.Scan() { send(stdin.Text()) } } // ---- Protocol helpers ----------------------------------------------------- // xor applies single-byte XOR with K=0x48 to every byte of b. // The transform is its own inverse. func xor(b []byte) []byte { out := make([]byte, len(b)) for i, v := range b { out[i] = v ^ XORKey } return out } // wordCount returns the number of Unicode-whitespace-delimited words. func wordCount(s string) int { return len(strings.FieldsFunc(s, unicode.IsSpace)) } // honkCount computes N per Section 4.4: // N = 2*W if W > 0; N = 3 if W == 0. Capped at MaxHonkCount. func honkCount(s string) int { w := wordCount(s) if w == 0 { return DefaultHonks } n := 2 * w if n > MaxHonkCount { return MaxHonkCount } return n } // buildResponse returns n SP-separated HONK tokens. func buildResponse(n int) string { tokens := make([]string, n) for i := range tokens { tokens[i] = "HONK" } return strings.Join(tokens, " ") } ]]> To build: