Summary

  • RFC 1922 required every ISO-2022-CN line containing Chinese characters to include its own designation and to shift back to ASCII before CRLF. A display could therefore begin at an arbitrary line without inheriting invisible state from earlier text.
  • Designation, locking shifts and single-character shifts made several Chinese repertoires usable in a 7-bit stream. They proved a byte grammar, not delivery, font coverage, sender identity or human comprehension.
  • Edition and vendor-extension parameters exposed which repertoire a message expected. The RFC made disagreement describable; only implemented decoders, transport paths and fonts made the text operational.

Line twenty could not borrow line nineteen's memory

Stateful encodings economise by changing how later bytes are interpreted. That bargain becomes fragile when a viewer does not start at byte one. A mail reader may reveal only the current window. A quote may begin in the middle. A damaged prefix may disappear while later lines survive. If the active character set lives only in earlier escape state, the visible bytes can be intact and still mean the wrong thing.

RFC 1922, published in March 1996 as an Informational document, made the line a recovery boundary. ISO-2022-CN began in ASCII. When a line used Chinese characters, it repeated the designation needed on that line. Before CRLF, the encoder issued SI and returned to ASCII. The next line began from a known state.

Those extra bytes were not decorative. They converted hidden history into local evidence. A decoder did not need to trust that it had observed every preceding line; it could reconstruct the current line from what the current line carried. The design also made failure narrower. A malformed or lost designation could damage one line without silently redefining all later lines.

Designation chose a table; shifting chose a moment

ISO-2022-CN separated two decisions that are easy to collapse. An escape designation associated a registered character set with a register. A shift then selected which register interpreted the following bytes. SO entered the designated double-byte set and SI returned to ASCII. A later designation for the same register replaced the old one.

SS2 and SS3 were shorter loans. Each applied only to the next two bytes—one Chinese character—and then interpretation resumed in the previous SI/SO state. That resumption mattered. A monitor that records only “Chinese mode” loses which set was designated, whether the change was locking or single-shift, and where the earlier state returned.

The extended form, ISO-2022-CN-EXT, admitted additional registered sets and planes. The specification reserved escape patterns containing placeholder final characters for registrations that did not yet exist, but prohibited their use until ISO assigned them. A vacant code point in a grammar was not permission to invent a public meaning.

Seven clean bits and eight vulnerable ones

The 7-bit forms were shaped for the mail infrastructure they had to cross. ISO-2022-CN and ISO-2022-CN-EXT kept their octets below 128, so high-bit preservation did not by itself require a Content-Transfer-Encoding. This did not make every message safe: MIME labeling, legal escape state and a capable decoder still mattered.

The 8-bit alternatives had a different exposure. CN-GB and CN-Big5 could travel as Base64 or Quoted-Printable through a 7-bit path, or directly where SMTP's 8BITMIME extension had actually been negotiated. Raw 8-bit text sent through an older 7-bit mailer could lose its high bit and become unreadable. A sender's local success could not certify the rest of the route.

The distinction kept three records separate. The MIME charset named an intended interpretation. Content-Transfer-Encoding protected representation across a constrained transport. 8BITMIME negotiated a transport capability. None authenticated the writer, guaranteed the receiving font, or proved what appeared on screen.

A year could narrow mistakes without becoming truth

Chinese standards changed editions. RFC 1922 introduced charset-edition so a message could state the edition year it expected. An implementation that understood the parameter could choose the right mapping. One that did not was instructed to ignore the parameter, potentially rendering against an older edition with a limited number of mistakes rather than manufacturing a new default.

charset-extension addressed another source of divergence: vendor or local glyph extensions. Registered values and private x- names could reveal that a message depended on an added repertoire. The label improved diagnosis, but it could not create the missing glyphs. Indeed, the RFC warned that such extensions could reduce interoperability.

Big5 and CNS 11643 exposed the same boundary. Conversion tables and vendor mappings remained implementation responsibilities. A valid byte stream could name a repertoire accurately and still meet a decoder whose table, edition or font differed. Encoding suggested a glyph tradition; it did not prove the sender's nationality or the reader's interpretation.

The line also had a physical width

RFC 1922 treated display layout as part of operational interoperability. Escape sequences occupied bytes but no columns. A Chinese character normally occupied two bytes and two display columns. Implementations were told not to split those two bytes across a line and were encouraged to keep lines around 75 columns, leaving room for the > inserted by mail quoting.

This was a modest form of end-to-end realism. A grammar could be correct while a reply operation damaged it at the margin. By budgeting for quoting and making each line restore state, the encoding anticipated ordinary transformations performed by mail software rather than assuming pristine carriage.

Related documents define context, not adoption

The primary record is RFC 1922. RFC 1468 and RFC 1557 supply related Japanese and Korean 7-bit mail designs. RFC 1521 supplies the contemporary MIME framework, RFC 1652 the negotiated 8-bit SMTP boundary, and RFC 2046 the later MIME media-type clarification. RFC 3629 records the later standardisation of UTF-8.

Together they show a design trajectory, not an installation census. RFC 1922 recommended at least sending and receiving ISO-2022-CN and receiving as many described encodings as practical. It did not prove that a named product complied or that migration to UTF-8 was automatic and lossless. Its Security Considerations section said security was not discussed.

Running-Code Primacy is useful here as a later discipline: the RFC and registered names describe a coordination surface, while parsers, relays and fonts determine operational reality. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption sharpens the boundary. The deterministic common core was small—designation, shift, byte range and reset—while repertoire support and adoption remained local. Neither note is evidence of the RFC authors' intent.

RFC 1922's enduring move was to spend a few repeated bytes so that the present did not depend on an invisible past. Every line returned to ASCII, and that retreat made the middle readable.