Resumen

  • RFC 2158 vinculó JPEG y GIF mediante nombres de partes, OID, tipos MIME y octetos copiados sin conversión; eran señales relacionadas, pero no equivalentes.
  • La subsección FTAM EMA GIF imprime image/jpeg, aunque su título, el nombre de la parte y el OID gif-image(4) señalan GIF.
  • El contexto respalda la hipótesis de un error de copia, pero el RFC Editor no registra hoy ningún erratum para RFC 2158; el texto tampoco demuestra qué emitió o decodificó una pasarela desplegada.

Una fila rompió su propia cadena de identidad

RFC 2158, publicada en enero de 1998, definió dos caminos breves para imágenes entre MIME y X.400. Las partes de cuerpo extendidas eran mime-jpeg-body bajo { mixer-bp-data 3 } y mime-gif-body bajo { mixer-bp-data 4 }, ambas sin parámetros. El documento también enumeró dos identificadores FTAM de la Electronic Messaging Association.

Tres de sus cuatro casos siguen un patrón limpio: JPEG extendido con image/jpeg; FTAM EMA JPEG con image/jpeg y un OID que acaba en jpeg-image(6); GIF extendido con image/gif. La cuarta subsección se titula «image/gif - FTAM EMA GIF», nombra la parte FTAM EMA GIF y da una ruta OID que termina en gif-image(4). Sin embargo, la línea intermedia imprime MIME Content-Type: image/jpeg, y la frase siguiente llama al OID uno asignado a JPEG.

La contradicción está dentro de una sola entrada. No hace falta imponer una convención moderna: tres identificadores dicen GIF, mientras una etiqueta y un sustantivo heredado dicen JPEG. No pueden describir a la vez el mismo formato.

«Sin conversión» elevó el coste del error

Las cuatro correspondencias declaran Conversion: None. La pasarela no tenía que decodificar un raster y volver a codificarlo en otro formato. Asociaba una representación X.400 con un tipo MIME y transportaba los octetos sin cambiarlos. Por tanto, una cabecera JPEG no convierte bytes GIF en JPEG, ni una rama OID denominada GIF convierte bytes JPEG en GIF.

RFC 2046 traza la frontera: dentro del tipo superior image, el subtipo identifica el formato concreto. El registro de tipos de medios de IANA mantiene entradas separadas para image/gif e image/jpeg. Un receptor suele elegir el decodificador por esa etiqueta, pero la etiqueta continúa siendo una afirmación sobre los octetos. Elegir la regla correcta, preservar el hash y lograr que un visor abra el archivo son pruebas distintas.

La norma compañera, RFC 2157, refuerza el patrón: relaciona mime-jpeg-body con image/jpeg y mime-gif-body con image/gif. No corrige RFC 2158 de forma implícita, pero explica por qué el implementador tenía varios campos que conciliar.

La corrección aparente sigue siendo una inferencia

La lectura más sólida es que la subsección FTAM EMA GIF debía decir image/gif y describir un OID asignado a GIF. Lo sostienen el título, el nombre de la parte, la hoja del OID y las entradas vecinas. El borrador MIXER previo también empareja la parte extendida GIF con image/gif, pero es anterior a las subsecciones FTAM y no contiene una versión corregida de la fila discutida.

La evidencia pública se detiene ahí. La búsqueda de errata del RFC Editor no muestra coincidencias para RFC 2158. «Probable errata tipográfica» es una conclusión analítica; «corregida oficialmente» no lo es.

Tampoco podemos reconstruir despliegues desde el papel. Un producto pudo obedecer literalmente el campo MIME, preferir el título y el OID, usar una corrección privada, inspeccionar las firmas binarias o no implementar nunca la ruta FTAM.

La especificación no puede declarar por el programa

Para demostrar lo que hizo una pasarela hacen falta la versión de la tabla, la parte de cuerpo elegida, el OID completo, el campo MIME y los bytes de entrada, los campos y bytes de salida, el controlador seleccionado y el resultado del decodificador. Un hash idéntico prueba continuidad binaria en el paso observado, no que la etiqueta fuera correcta. Una imagen visible prueba que un controlador la aceptó, no que todos los receptores elegirían el mismo.

La lección es una disciplina de capas. El documento, la implementación y el resultado observado pueden coincidir, pero ninguno hereda la prueba de los otros. RFC 2158 no invalida las etiquetas: obliga a tratarlas como una parte de una identidad compuesta. Si discrepan, la contradicción debe resolverse antes de usar el rótulo como sustituto de los bytes o del comportamiento.

Fuentes