Summary

  • RFC 1502 described how X.400 GeneralText could carry several registered character sets, with ISO 2022 designations and shifts determining what the bytes meant.
  • Its receiving program was told to mark characters it could not represent and never replace one with the native character at the same bit position. Generation advice was no excuse for the reader to guess.

The bad rendering is more dangerous than a blank square. A blank square tells the reader that a machine could not show part of the message. A wrong character can pass as the sender's word. Harald Alvestrand put that distinction into the receiving rules of an August 1993 document about X.400 mail. Internationalization was becoming a problem of interpretation, not just a problem of moving eight bits across a network.

GeneralText could announce the character sets used in its envelope and body parameters. The stream itself could switch among sets using ISO 2022 escape and shift sequences. At the start, the decoder assumed IA5 in G0 and the standard control set in C0; another starting state had to be announced. To interpret a later byte, the reader needed to know which set was active at that point. The list of sets was an inventory, not a translation of every byte.

RFC 1502 offered senders a tidy plan: keep US-ASCII in G0, use an appropriate ISO 8859 set in G1 when possible, and add further sets under specified conditions. That arrangement kept ordinary ASCII bytes stable while other scripts occupied another part of the code page. But the recipient had a tougher job. The document explicitly told receiving agents not to assume senders followed those recommendations. Mail arriving from a real world of gateways and old software would not tidy itself for the convenience of the next decoder.

The rendering rule was therefore severe. A capable reader should identify IA5 and its native sets however they were designated. It should always indicate a character that the output device could not represent. It should never put a local character on screen merely because that character shares the unknown input's bit position. The bytes survived the journey; that coincidence did not give the substitute glyph the sender's meaning.

The same section preferred a mode that shows fallbacks and another that marks unrenderable characters, plus a way to save the content with its character-set information. These expectations also reached gateways converting GeneralText into another format such as MIME. A message could be made readable by a particular screen while still needing an archival copy of the state that gave its bytes meaning.

There was an even sharper boundary at conversion. If the chosen destination sets could not express a character, section 5 offered a substitute marker, a documented mnemonic, a human-readable fallback, or refusal. If the message prohibited conversion with loss, the choices narrowed to refusal. The RFC Editor record now labels RFC 1502 Historic; its 1993 status text called it a standards-track protocol. The paper names no client whose screen followed the rule. It does leave an enduring editorial demand for software: when you cannot show the author's letter, show the failure rather than forge a convincing replacement.