Resumen

  • RFC 2049 definió cómo debía comportarse un agente cuando el vocabulario abierto de MIME superaba los formatos que conocía.
  • Una codificación, un charset o un tipo no textual desconocidos descendían hacia application/octet-stream; los bytes no textuales no debían mostrarse como texto crudo.
  • “Safe” significaba atravesar sistemas RFC 821/822 conformes conocidos y no salpicar bytes en la pantalla, no demostrar identidad, integridad, archivo inocuo, visualización ni resultado.

La interoperabilidad empezó por admitir ignorancia

Ningún cliente podía implementar todos los subtype presentes y futuros. Convertir esa totalidad en requisito habría hecho caducar la conformidad con cada extensión; dejar el caso sin regla habría permitido que los mismos datos se imprimieran, ejecutaran o adivinaran de modos incompatibles.

RFC 2049 fijó un suelo. El agente conforme generaba MIME-Version: 1.0, reconocía Content-Transfer-Encoding, decodificaba quoted-printable y base64 y distinguía 7bit, 8bit y binary. Si el transporte inferior no admitía datos de ocho bits o binarios, el emisor debía codificarlos y etiquetarlos. La etiqueta describía la transformación esperada, no demostraba su ejecución.

Si la propia codificación de transferencia era desconocida, el Content-Type familiar no concedía permiso para interpretar. La entidad se trataba como application/octet-stream. Primero había que reconstruir los octetos; después podía decidirse si el formato era comprensible.

EID 5470 registra que la frase original parece atribuir un Content-Type a la codificación y propone explicitar “entidad MIME con”. Está Held for Document Update: aclara la lectura, pero no es texto ya sustituido.

El tipo superior compraba una pista, no comprensión

Para text, el mínimo era mostrar US-ASCII e informar al usuario sobre otros charset. Un subtipo textual desconocido podía ofrecerse en bruto cuando el charset era conocido y tras convertir la forma canónica en forma local. Charset desconocido significaba octet-stream.

Los subtipos desconocidos de imagen, audio y vídeo también retrocedían a octet-stream. Para application, el receptor debía poder quitar base64 o quoted-printable y guardar el resultado en un archivo del usuario. Custodiar no era ejecutar. RFC 2046 advertía que un visor general hereda el peligro de su formato más peligroso.

En los compuestos, la regla cambiaba: reconocer mixed, alternative y digest; tratar un multipart desconocido como mixed; presentar message/rfc822 recursivamente; convertir un message desconocido en octet-stream. Un Content-Type totalmente desconocido también se volvía octet-stream sin parámetros. Guardarlo o escoger un programa eran opciones locales, no órdenes automáticas.

La palabra “seguro” terminaba antes de la acción

RFC 2049 llamó seguro al envío de datos correctamente marcados porque un sistema conforme podía conservarlos como binario indiferenciado y no volcarlos sobre la pantalla de quien esperaba texto. También los consideró seguros frente a sistemas RFC 821 y RFC 822 conformes conocidos: no romperían esos sistemas ni serían rotos por ellos.

Nada de eso convierte los bytes en benignos. Un handler puede tener fallos; una decodificación correcta no autentica al remitente, no prueba integridad, consentimiento, presentación correcta ni lectura. Informar el nombre de un charset o permitir guardar un archivo ya podía satisfacer el mínimo. La negativa útil era parte de la interoperabilidad.

Lo desplegado y defectuoso no se volvió normativo

El documento reconoció numerosos MTA no conformes que alteraban mensajes según el almacenamiento local o simplemente estaban rotos. NUL, TAB, espacios finales, líneas largas, caracteres no invariantes, un punto aislado y From al comienzo podían cambiar. Base64 obedecía el alfabeto y las líneas más portables; quoted-printable no garantizaba todos los gateways descritos.

La propia RFC negó que aquello fuera una recomendación. RFC 821 prohibía alterar espacios o plegar líneas. Eran prácticas BAD e invalid, aunque reales. Diseñar para resistirlas no las legitimaba.

La página actual de RFC Editor muestra Draft Standard; el documento histórico dice Standards Track y noviembre de 1996. Eso acredita una publicación, no implantación universal. EID 3933, Verified, corrige la referencia de encoded-word hacia la gramática de RFC 822 y las reglas de RFC 2047; no convierte texto de presentación en identidad.

El logro fue una ignorancia disciplinada: decodificar lo conocido, aislar lo desconocido y no llamar comprensión a la simple posesión de bytes.

Fuentes