Summary

  • RFC 1489 registered the MIME name koi8-r for a character encoding already used by a large Unix and network community in the former Soviet Union; the memo did not make it an Internet or international standard.
  • The published mapping makes a remarkable damaged projection possible: clearing bit 7 from core Russian-letter octets produces rough Latin correspondences with reversed case. This is a computed property of the table, not a documented historical delivery result.
  • A readable projection is not the original record. It cannot reliably distinguish original ASCII from damaged Cyrillic in mixed text, prove the declared charset, authenticate content or establish what a reader saw and understood.

The reassuring ruin

Suppose an old message reaches an archive as rUSSKIJ TEKST. It looks broken, but not opaque. A Russian reader can hear something through the inverted capitals: “Русский текст”, Russian text. The temptation is to call the message recovered.

That conclusion outruns the evidence. The surviving characters are ASCII. They may be the result of clearing the high bit from KOI8-R bytes, but they may also have been ASCII from the beginning. The reader has recognized a plausible phrase; the archive has not recovered the erased binary distinctions.

This graceful failure is a real property of the mapping published in RFC 1489. It is not a claim the RFC makes about a named damaged message. Reproducing the effect requires no folklore. Encode Русский текст as KOI8-R and the bytes are F2 D5 D3 D3 CB C9 CA 20 D4 C5 CB D3 D4. Clear bit 7 from each high byte and the result is rUSSKIJ TEKST.

The experiment proves a relation between two byte sequences. It does not prove that any observed ASCII string travelled by that path.

Registration followed use

The RFC Editor record dates the memo to July 1993 and now classifies it as Informational in the Legacy stream. Andrew A. Chernov wrote it from the RELCOM Development Team. Its opening is unusually candid about authority.

KOI8-R was not an international standard, the text said. Its underlying specification was unpublished and drew on several published sources, including GOST 19768-74, ISO 6937/8, INIS-Cyrillic and ISO 5427. Yet a very large user community, including RELCOM, already supported it. For Unix and global-network applications in the former Soviet Union, the memo called it a de-facto standard. The Society of Unix User Groups sought registration because running use needed a common name.

Publication therefore did not summon an encoding into existence. It made an operating convention inspectable and referenceable. This is the order emphasized by Heng Lu's account of running-code primacy: practical adoption disciplined the specification. The RFC recorded a mapping and MIME name; it did not acquire a mandate over every Russian-language system.

That institutional modesty matters. “Registered” answered which mapping the name should select. It did not certify that KOI8-R was optimal, universally deployed, correctly implemented or appropriate for every application.

The table was more than an alphabet

RFC 1489 divided the octet space cleanly. The lower half coincided with ASCII. The upper half mapped not only Cyrillic letters but box-drawing pieces, blocks, mathematical signs, a copyright sign and other terminal-era graphics. The Unicode Consortium mapping file later rendered the full table in a machine-readable form based on the RFC.

The letter positions explain the damaged projection. KOI8-R byte C1 maps to Cyrillic small а; clear its high bit and it becomes ASCII 41, capital A. Byte E1 maps to Cyrillic capital А; clear the bit and it becomes ASCII 61, small a. The case reversal is not an incidental display setting. It follows from where the two Cyrillic cases sit relative to the Latin alphabet.

The order is phonetic only in a rough engineering sense. Russian Р falls toward Latin R, С toward S, and Т toward T; other letters need approximations such as W, Q, X or punctuation. The property makes a damaged sentence guessable to someone who understands the failure mode. It does not create a linguistically complete transliteration.

Nor does it protect the whole upper half. A box-drawing octet with its high bit cleared may become a control character or ordinary punctuation with no visual kinship to the original. A diagram, table border or mathematical mark can be destroyed even while its neighbouring Russian word remains partly legible. “KOI8-R survives seven bits” is therefore too broad. Some letter information falls into a useful shadow; the eight-bit record does not survive.

Two originals can collapse into one survivor

Lossy transformations are dangerous when their output looks meaningful. Consider ASCII A at byte 41 and KOI8-R Cyrillic small а at byte C1. After bit 7 is cleared, both are 41. The survivor cannot tell the archivist which source existed.

A wholly Russian sentence provides context. Mixed material does not. Source code, mail headers, product names, file paths, transliterated words and Cyrillic prose can share one message. An automatic “repair” that adds the high bit to every Latin-looking letter will corrupt genuine ASCII. A repair that leaves the survivor unchanged will abandon damaged Cyrillic. Language models and dictionaries may rank hypotheses, but likelihood is not provenance.

Case makes the ambiguity more subtle. The damaged projection reverses Cyrillic case. An operator may normalize case before noticing the pattern, destroying another clue. Search indexing may fold capitals. A log collector may rewrite control positions. A later UTF-8 export may faithfully encode the wrong inferred Latin characters and thereby give a damaged guess the appearance of a clean modern record.

Recovery consequently needs the original octets, or independent evidence strong enough to reconstruct them. Readability helps triage. It does not close the evidentiary gap.

A label chooses a decoder; it does not inspect the body

The current IANA Character Sets registry still lists KOI8-R with MIBenum 2084 and alias csKOI8R, pointing to RFC 1489. That durable record is useful. A system encountering charset=koi8-r can identify the intended byte-to-character mapping.

MIME's later consolidated rules in RFC 2046 explain why the label matters. The charset parameter tells a receiver how the sender intended a text body's octets to be interpreted. Eight-bit text may also require a content-transfer encoding on mail paths that do not preserve all eight bits. These are separate claims: one names the mapping; the other protects transport.

The RFC Editor record for RFC 2046 shows its standards lineage, but a standard field remains an assertion supplied in a message. A wrong koi8-r label does not become true because it is syntactically valid. A missing label does not authorize a receiver to guess silently. A correct label does not prove that an intermediary preserved the bytes.

RFC 2978 later made the registration boundary explicit. Registration associates a unique name with a fully specified charset and indicates whether it can be used in MIME text. General applicability belongs to the application protocol, not the registration act. The RFC Editor record identifies that document as a Best Current Practice; it clarifies later governance and should not be projected backwards as the exact procedure Chernov followed in 1993.

The distinction is a version of Heng Lu's reality layers. The registry proves an assigned name. The header records a claimed mapping. The stored bytes are the material record. The decoder produces characters. A font produces glyphs. A reader produces an interpretation. Each layer can be accurate while a neighbouring one is wrong.

Local extension did not erase the shared base

Five years later, RFC 2319 described KOI8-U. It kept every KOI8-R Russian letter in place and used other upper-half positions for four Ukrainian letters. The RFC Editor record classifies that work as Informational too.

Its history is revealing. The Ukrainian encoding had been adopted at a conference of Internet service-provider postmasters in 1992 and completed later. Compatibility did not require one universal institution to redesign the entire table. A local community preserved the shared Russian-letter surface and filled a linguistic gap.

This fits the model of minimum initial specification and localized future decision. A narrow common mapping can coordinate exchange without acquiring authority over every future alphabet, application or archive. But compatibility must be named precisely. KOI8-U compatibility for Russian letters does not mean a KOI8-R decoder can represent the added Ukrainian letters. A label that collapses the two removes the very information the extension introduced.

Unicode changed the shared destination, not the archive's past

RFC 3629 defines UTF-8 for the Unicode repertoire. Like KOI8-R, it preserves ordinary ASCII byte values. Unlike KOI8-R, it uses variable-length sequences and a universal character set rather than a language-specific upper half. Its RFC Editor record documents a later standards-track settlement.

UTF-8 made a far larger interoperability surface possible. It did not retroactively identify an unlabelled legacy file. To convert KOI8-R correctly, an archivist still needs the source bytes and the correct source mapping. The Unicode mapping file warns that its RFC-based mapping does not claim identity with every vendor's Code Page 878. Even a successful character conversion may omit vendor differences that mattered to a specific record.

An archive can preserve two receipts at once: the original KOI8-R octets and hash, and a normalized Unicode representation with the converter, mapping version and exceptions recorded. Deleting the source because the UTF-8 text looks right trades durable evidence for convenience.

RFC 1489's enduring lesson is not that old encodings were quaint. It is that resilience has a scope. A byte table can arrange for damage to fail in a way a person may recognize. It cannot make lossy damage lossless, make a registry entry inspect a message, or make a reader's intuition stand in for the original record.

Sources