Resumen

  • El RFC 1557, de diciembre de 1993, describe un cuerpo de texto ISO-2022-KR: empieza en ASCII, designa KSC 5601 mediante ESC $ ) C, pasa al coreano con SO y vuelve a ASCII con SI.
  • Para escribir coreano en una cabecera, emplea EUC-KR y lo envuelve como palabra codificada B o Q del RFC 1522. El asunto y el cuerpo exigen lecturas independientes.

La misma carta llegó con dos uniformes

Supongamos que una persona abre un correo y entiende la línea «Reunión aplazada», pero encuentra símbolos incoherentes donde debería estar el nuevo horario. También puede ocurrir lo inverso. El fallo llama la atención porque la pantalla presenta asunto y mensaje como una sola pieza. En los bytes, los separa una decisión de diseño: la cabecera pertenece al lenguaje estructurado del correo y el cuerpo a un flujo de texto más largo.

El RFC 822 organizó el mensaje con campos de cabecera antes de una línea en blanco y un cuerpo después. Los programas de correo trataban los primeros como piezas con puntuación y reglas propias. Podían plegar líneas o reorganizar direcciones. El texto posterior se procesaba de otra manera. Al llevar caracteres coreanos a ambas zonas, la solución debía respetar esa diferencia.

U. Choi, K. Chon y H. Park describieron la práctica en el RFC 1557. Según el propio documento, el método se había definido en 1991 y ya circulaba ampliamente en redes IP coreanas. La publicación de 1993 fijó su descripción para mensajes de texto sin adornos. Su detalle más importante es una asimetría deliberada: el cuerpo utiliza un repertorio de siete bits con cambios de estado; la cabecera utiliza bytes EUC-KR empaquetados para sobrevivir a sus propias reglas.

El cuerpo arranca en ASCII. La secuencia ESC $ ) C anuncia KSC 5601. Después, SO ordena interpretar parejas de bytes como caracteres de ese conjunto, que incluye hangul y hanja; SI devuelve la lectura a ASCII. La etiqueta MIME de esa parte es ISO-2022-KR. El mecanismo funciona como una aguja ferroviaria: el mismo tren de bytes toma vías distintas según el último cambio de posición que haya visto el lector.

La descripción coloca ESC $ ) C al comienzo de una línea, antes del primer SO. La gramática formal del RFC permite esa única designación seguida de varias líneas que contienen coreano; los autores dan prioridad a la gramática si la descripción parece exigir otra cosa. Para reconstruir una copia antigua hay que encontrar esa designación inicial y después seguir cada SO y SI. Si falta el comienzo del mensaje, las líneas posteriores pueden conservar sus bytes y perder la pista necesaria para leerlos.

El formato del cuerpo cabe en siete bits. Por ese motivo, explica el RFC, no requiere por sí mismo una cabecera Content-Transfer-Encoding. Los autores añaden una observación situada en su tiempo: el software coreano de entonces no admitía aplicar Base64 o Quoted-Printable a un cuerpo ya codificado así. Es información sobre las herramientas disponibles en 1993, útil para entender por qué eligieron esta ruta.

El asunto pasa por otra ventanilla. Sus caracteres coreanos se convierten a EUC-KR y luego se presentan como palabras codificadas B o Q conforme al RFC 1522. La envoltura =?charset?encoding?encoded-text?= permite que los programas antiguos vean caracteres ASCII imprimibles mientras un lector preparado recupera el texto coreano. En la cabecera figura EUC-KR; en el cuerpo, ISO-2022-KR. Aplicar la misma receta a ambos es un modo eficiente de fabricar una avería.

La experiencia humana termina con una frase y un horario. Por debajo, dos decodificadores han tenido que ponerse de acuerdo con las pistas que dejó quien envió el mensaje. El RFC 1557 conserva la costura entre ellos, justo donde un archivo migrado puede ocultar la causa de un error.