Resumen

  • El RFC 1049 propuso un campo Content-Type para cuerpos estructurados como PostScript, TeX o TROFF. El mensaje seguiría viajando con caracteres ASCII admitidos por el correo de la época, y el lector podría seleccionar un procesador para presentarlo.
  • El campo también podía nombrar una versión y recursos auxiliares. Como aún faltaba un intercambio de capacidades, el remitente llevaba su propia lista de destinatarios preparados; el RFC 2045 amplió después esa idea dentro de MIME.

Que un documento llegue intacto no garantiza que llegue como documento. En un buzón de 1988, un archivo PostScript podía convertirse ante los ojos del lector en una pared de órdenes para una impresora. Las letras habían viajado sin problemas; la página con fórmulas y tipografía seguía escondida detrás de ellas. El RFC 1049, publicado por Martin Sirbu en marzo de aquel año, propuso una salida: que el propio mensaje anunciara qué clase de tratamiento necesitaba.

El correo regido por RFC 822 tenía cabeceras definidas y un cuerpo construido con caracteres ASCII. La gente ya empleaba ese cuerpo para enviar TROFF, TeX, Scribe, SGML, DVI y PostScript. Todos podían presentarse como texto permitido para el transporte y, al mismo tiempo, exigir una interpretación especial para mostrar el resultado previsto. Una cabecera Content-Type permitiría al programa lector reconocer la técnica y entregar el cuerpo al procesador correspondiente. La ruta de correo seguiría llevando los mismos caracteres; la decisión de presentación recaería en la máquina receptora.

La etiqueta de Sirbu tenía más piezas que una pegatina genérica. Primero aparecía el tipo, con nombres como POSTSCRIPT y TROFF y una vía X- para acuerdos privados. Podían seguirle un número de versión, una referencia a recursos y un comentario. El RFC menciona versiones de LaserPrep para PostScript y los auxiliares eqn, tbl y me para TROFF. Saber que la receta pide horno sirve de poco cuando el horno está en otra cocina. La referencia al recurso permitía declarar precisamente esa dependencia.

Quedaba el problema de los invitados. Un destinatario sin intérprete podía recibir el mensaje ASCII y ver los comandos sin convertir. ¿Cómo averiguaba el remitente qué lectores estaban equipados? El RFC estudiaba tres caminos: una base de datos local de capacidades remotas, una negociación durante el transporte SMTP que transformara el mensaje, o un directorio con información sobre los sistemas receptores. La primera opción exigía actualización continua; la segunda tocaba las implementaciones de correo y dejaba rutas entre redes fuera de su alcance; la tercera ampliaba el trabajo de los servicios de nombres.

Para empezar a probar el campo, Sirbu eligió el procedimiento más humano de todos: el remitente tendría su lista privada de personas capaces de abrir cada formato. La cabecera estandarizaba el nombre del plato; la libreta personal decidía a quién se lo podían servir. El documento también dejaba a cada programa lector libertad para reaccionar ante un campo válido. Identificar una técnica, disponer del intérprete y mostrar bien el resultado eran trabajos diferentes.

El RFC 2045 describió más tarde el Content-Type de MIME como una generalización del RFC 1049. MIME añadió tipo y subtipo de medio, parámetros y otros campos, entre ellos MIME-Version y Content-Transfer-Encoding. Su especificación consideró la sintaxis de 1988 más sencilla y en gran medida compatible. La aportación temprana merece su propio foco: el correo aprendió a declarar cómo debía leerse mientras la información sobre las capacidades del destinatario seguía en manos del remitente.

La etiqueta ahorró al lector una adivinanza frente a la pantalla de comandos. A cambio puso en primer plano preguntas más caras: ¿quién tiene el intérprete, la versión y el recurso auxiliar? Durante un tiempo, la base de datos decisiva fue la memoria de quien pulsaba «Enviar».