NAK (Negative Acknowledge) is ASCII code point 21 (0x15), Unicode U+0015. It is a C0 control character that a teleprinter sent when a received data block failed its integrity check — the negative counterpart to ACK (0x06). In IBM BSC and ISO 1745 link-control procedures, NAK tells the sender to retransmit the last block, forming the core error-recovery loop alongside ACK. XMODEM adopted the same role: a 0x15 reply after a corrupted 128-byte packet triggers immediate resend. Ctrl+U emits 0x15, though Unix shells long ago remapped that keystroke to "kill line" instead. UTF-8 encodes it as the single byte 0x15; Unicode classifies it as Cc (Control) with the alias NEGATIVE ACKNOWLEDGE.
unsigned char resp = 0x15; // NAKif (resp == 0x15) retries++; // receiver rejected frameframe[0] = resp; // store control byte
NAK (ASCII 21) means 'I received your data, but something is wrong.' It's the negative counterpart to ACK — the receiver is asking the sender to retransmit because the data was corrupted, incomplete, or invalid.
NAK is an active rejection — it confirms the receiver is alive and listening, but the data was bad. No response (timeout) might mean the receiver is offline, busy, or the data never arrived. NAK says 'I heard you, try again'; silence says nothing.
The byte itself is rare, but the concept is everywhere. HTTP 4xx/5xx status codes, TCP negative acknowledgments, and NACK in message queues all serve the same purpose — telling the sender 'that didn't work, here's what went wrong.'
Ctrl+U generates NAK (ASCII 21). In most modern shells, Ctrl+U is intercepted to clear the current input line (a readline binding), so the raw NAK byte rarely reaches applications.