Resumen

  • En RFC 1502, X.400 GeneralText anunciaba los juegos de caracteres usados, pero las secuencias de designación y cambio ISO 2022 fijaban el significado de cada byte dentro del mensaje.
  • El programa receptor debía señalar un carácter que no pudiera mostrar. Jamás debía sustituirlo por el carácter nativo que ocupara la misma posición binaria; tampoco podía confiar en que el emisor siguiera las recomendaciones de composición.

Un cuadrado vacío interrumpe la lectura. Un símbolo equivocado puede cambiarla sin avisar. Harald Alvestrand eligió el primer problema en su documento de agosto de 1993 sobre texto internacional en X.400. El correo podía haber transportado los bytes intactos y aun así fallar en el último metro: la pantalla del destinatario.

GeneralText admitía varios juegos registrados en un mensaje. La envoltura y los parámetros del cuerpo enumeraban los utilizados; dentro del flujo, las secuencias ISO 2022 podían designar y activar otros juegos. El estado inicial suponía IA5 en G0 y el conjunto de control ordinario en C0. Si el emisor necesitaba otra configuración desde el comienzo, debía anunciarla. Conocer la lista de juegos era útil, pero para interpretar un byte había que seguir los cambios de estado hasta ese punto.

RFC 1502 aconsejaba escribir ASCII en G0 y, cuando encajara, usar ISO 8859 en G1. Así los caracteres ASCII conservarían sus mismos bits. Después le quitaba al destinatario una excusa cómoda: el lector no debía dar por hecho que el remitente había respetado esa receta. Había que procesar el mensaje recibido, incluidas sus designaciones reales, no el mensaje que la guía habría preferido recibir.

La instrucción de visualización era tajante. Un lector capaz de GeneralText debía reconocer IA5 y sus juegos nativos, señalar cualquier carácter que su dispositivo no pudiera representar y nunca dibujar el carácter local que coincidiera casualmente en la misma posición binaria. Ese reemplazo silencioso adjudicaría al autor una letra que solo pertenecía al repertorio de la máquina.

El documento prefería además ofrecer una vista con alternativas y otra donde los caracteres imposibles quedaran identificados, y guardar el contenido junto con la información sobre sus juegos. La regla alcanzaba también a pasarelas que transformaban GeneralText en otro formato, como MIME. El archivo conservado y la lectura mostrada debían poder volver a compararse.

Cuando ningún juego de destino contenía un carácter, la sección 5 permitía un marcador de sustitución, una mnemotecnia con aviso aparte, un recurso legible para una persona o rechazar la conversión. Si el mensaje prohibía la pérdida, quedaba solo el rechazo. El registro actual del RFC Editor indica estado Historic; la portada original hablaba de un protocolo en la vía de normalización de 1993. El texto no documenta un cliente concreto. Sí fija una responsabilidad del lector: confesar que no puede dibujar una letra antes de hacer pasar otra por auténtica.