Resumen

  • La «casi copia de bytes» de RFC 2159 también convertía parámetros, invertía el orden de bits, rellenaba páginas e insertaba una frontera de seis EOL.
  • El regreso sin pérdida dependía de conservar límites de página, EOL finales y bits DCS sin nombre; un hash igual del cuerpo no demostraba la restauración del mismo objeto fax.
  • Una vuelta estructural correcta no probaba que el receptor admitiera la codificación, la resolución o el ancho, ni que la imagen resultara fiel y utilizable.

«Casi» nombraba el trabajo que faltaba

Publicada en enero de 1998, RFC 2159 definió cómo transportar en MIME datos que ya estaban codificados como fax Grupo 3 y cómo relacionarlos con X.400. No presentó image/g3fax como formato general de imagen. Su misión era conservar una representación existente a través de dos sistemas de mensajería.

El objeto tenía tres clases de estado: opciones de codificación, estructura de páginas y bits T.4 de cada página. Las opciones se trasladaban a parámetros MIME; la secuencia de BIT STRING de X.400 se convertía en un cuerpo continuo con delimitadores; los datos usaban otra convención de orden dentro del byte.

La anterior RFC 1494 definía Byte Copy como copiar sin conversión. G3Fax llevaba desde entonces el calificativo nearly. No era necesario descomprimir y volver a comprimir la imagen, pero sí reconstruir su envoltura.

Los valores por omisión también viajaban

MIME podía expresar longitud y ancho de página, codificación unidimensional, bidimensional o sin compresión, resolución fina o gruesa, número de páginas y una Device Control String en Base64. Cuando faltaban los parámetros, regían A4, A4, una dimensión y resolución gruesa. La ausencia elegía un valor.

Los números de bit de las opciones no coincidían en T.30 y X.400 porque cada sistema contaba desde un extremo distinto del octeto. La pasarela debía mapear significado, no posición impresa. Esa traducción tampoco era la misma operación que invertir después los bits de cada byte del cuerpo.

Si la cadena de control activaba un bit sin parámetro específico, RFC 2159 pedía incluir DCS. A la vez advertía que esos NonBasicParameters no garantizaban interoperabilidad. Conservar una opción desconocida mantenía la evidencia, pero no la implementaba en el destino.

El límite de página se construía

X.400 guardaba una secuencia ASN.1 de BIT STRING, uno por página. MIME necesitaba un solo cuerpo. RFC 2159 eligió como separador seis EOL consecutivos; cada EOL tenía once ceros y un uno. El conjunto debía empezar en un límite de byte, por lo que se añadían ceros de relleno.

La secuencia era 00 10 01 00 10 01 00 10 01 y, según el RFC, no podía aparecer dentro de la imagen. Así se podía localizar una página sin renderizarla. Pero la posición del límite y la cantidad de relleno pasaban a formar parte del recibo. Un flujo idéntico sin esas divisiones no probaba las mismas páginas.

Al ir de X.400 a MIME, se retiraban los EOL finales, se cambiaba el orden de bits a la convención de Internet, se completaba el byte, se añadían seis EOL y se concatenaban las páginas. Al volver, se separaba por los seis EOL, se conservaban los EOL finales, se invertían los bits de cada byte y se reconstruía la secuencia ASN.1.

La instrucción de conservar los EOL era un cambio expreso frente a RFC 1494, que había ordenado eliminar EOL y relleno en el retorno. La etiqueta general seguía siendo «casi copia», pero la regla exacta de reversión había cambiado.

El hash debe declarar qué capa mide

Un hash estable del cuerpo MIME demuestra continuidad de esos octetos durante el tramo observado. No demuestra que la pasarela anterior eligiera el orden correcto. Los bytes empaquetados del BIT STRING y los bytes MIME pueden diferir incluso en una conversión correcta, porque la inversión es deliberada.

La comparación válida registra la longitud significativa de cada página, los bits ASN.1 no usados, la regla de orden, el relleno y los desplazamientos de cada separador. En el regreso debe restaurar número de páginas, bits significativos, parámetros y DCS.

La RFC 2157 fijó el criterio: equivalence era el conjunto de dos mappings que daban una conversión sin pérdida. Obtener una salida válida en una dirección solo demostraba una flecha.

Reversible no quería decir visible

La guía de implementación separó la estructura de la utilidad. Sin fineResolution, los píxeles eran el doble de altos que de anchos. Algunas longitudes y la resolución fina se consideraban más fáciles de soportar que los anchos B4 o A3. Además, ciertos equipos fallaban si una línea no contenía exactamente el número declarado de píxeles, por ejemplo al omitir el blanco derecho.

La pasarela puede restaurar cada página y el decodificador no admitir el modo. También puede aceptar el flujo y mostrar una geometría errónea. Una página plausible puede estar recortada. Aceptación sintáctica, reconstrucción, dimensiones, apariencia y lectura humana son hechos distintos.

El registro actual de IANA conserva image/g3fax; sus tablas históricas MIME/X.400 lo enlazan con g3-facsimile. El registro prueba un identificador público, no una implementación desplegada ni la capacidad del receptor.

Una prueba defendible empieza con parámetros X.400, DCS, páginas, longitudes significativas y huellas por página, además de versión de pasarela y tabla. En MIME guarda parámetros, relleno y posiciones de frontera. La vuelta compara la secuencia restaurada. Solo después se verifican modos, píxeles por línea, dimensiones y renderizado.

Los textos de Lu Heng sobre código ejecutado, especificación mínima y capas de realidad aportan una lente explícita: regla, ejecución, representación y resultado no comparten automáticamente la misma prueba.

El «casi» de RFC 2159 enumeraba lo que quedaba fuera de una copia. Sin opciones, páginas, orden, relleno o capacidad, un cuerpo intacto podía dejar de ser el fax del que procedía.

Fuentes