Resumen

  • En una reunión de BBN del 10 de enero de 1979, los participantes reconocieron que las variantes locales y las implementaciones parciales estaban perjudicando el correo común de ARPANET. Prohibieron espacios en nombres de usuario usados entre hosts, varios signos @ en un buzón y las direcciones Include y Postal de RFC 733 que casi nadie admitía. Tampoco habría nuevos cambios en los códigos FTP de MAIL/MLFL.
  • Duane Adams arbitraría los cambios menores discutidos mientras el trabajo de voz, fax e imagen avanzaría en un servicio de próxima generación. Jon Postel publicó el recuerdo de la reunión el 1 de marzo de 1982 y atribuyó problemas persistentes a que las conclusiones no se habían documentado ni trasladado a las especificaciones.

Imagine una cinta común que lleva cartas entre salas de ordenadores. Cada sala pega a la cinta una mejora ingeniosa. Una extensión resulta útil en su sala y atasca la máquina de la siguiente. En enero de 1979, una reunión en BBN examinó el correo de ARPANET como servicio completo y decidió dejar de añadir ocurrencias a la cinta. Jon Postel contó la historia en la RFC 808 tres años después. La cinta es una imagen; el retraso documental es un hecho que el propio Postel puso al comienzo del texto.

Los programas de correo se habían multiplicado sin un diseño único. El apéndice ofrece una lista preliminar de lectores, remitentes y servicios en máquinas muy distintas. Los asistentes mencionaron respuestas FTP extrañas, nombres mal calificados, problemas al actualizar tablas de hosts y errores que llegaban al emisor tarde. Un sistema local podía sentirse cómodo mientras el mensaje se descomponía al cruzar al siguiente. Por eso Duane Adams pidió mirar el servicio total, más allá de cada interfaz.

La causa tenía dos caras: el protocolo admitía variaciones y la mayoría de sistemas solo implementaba parte de él. Un retoque menor en un sitio desencadenaba un fallo inesperado en otro. El acuerdo fue estabilizar pronto el sistema en funcionamiento. Se permitirían unas pocas modificaciones pequeñas, con Adams como árbitro de las dudosas. Nadie obligaría de repente a todos los programas a completar cada posibilidad escrita en RFC 733.

Las reglas concretas tenían filo. Entre hosts, un nombre de usuario con espacios podía romper programas y quedaba fuera. Lo mismo ocurría con varios @ en un buzón. Las formas de dirección Include y Postal, previstas en RFC 733 pero poco implementadas, se retiraban del compromiso del servicio. Los códigos de respuesta FTP para MAIL/MLFL se congelaban. La libertad de un emisor terminaba donde empezaba el programa receptor que debía entenderlo; esa frontera era más importante que la elegancia del formato.

El freno convivió con un proyecto mayor. En la discusión se habló de correcciones montadas sobre correcciones y de pasar a una versión dos. Para la próxima generación se aprobó usar datos estructurados y explorar voz, fax y gráficos. Jack Haverty recordó el lenguaje MSDTP de RFC 713 como una posible herramienta de definición. Postel recibió un encargo para febrero de 1979; la nota de 1982 dice que el borrador se convirtió en IEN-85 y fue superado por RFC 759 y RFC 767. Así se separaba una red compartida que necesitaba estabilidad de un laboratorio que necesitaba probar ideas nuevas.

También entraron en la sala los ordenadores personales. Como no estarían siempre encendidos para recibir correo, se esperaba que sus usuarios guardaran el buzón en una máquina grande y lo consultaran después. Los usuarios de NSW no pertenecían a un host concreto, de modo que user@host no describía bien su identidad; Bob Thomas sugirió tratar NSW como host virtual. Disponibilidad, identidad y encaminamiento exigían más arquitectura de la que cabía en otra pequeña excepción local.

La ironía final quedó escrita con retraso. El grupo quería impedir que reglas ambiguas y software incompleto siguieran causando choques. No documentó sus conclusiones y no revisó las especificaciones. En marzo de 1982, Postel reconoció que su reconstrucción era incompleta tras tres años y que aquella laguna había alimentado problemas continuos. Un acuerdo oral en una sala de Cambridge no servía de manual al programador que escribía correo en otra parte.

La RFC 808 defiende una virtud poco vistosa: reducir lo que promete un servicio común hasta lo que sus participantes pueden ejecutar, mientras se construye aparte el sistema que permitirá más. El correo multimedia tenía futuro; la cinta antigua no tenía por qué tragárselo antes de tiempo. La pieza que faltó en 1979 fue, precisamente, hacer público dónde habían puesto el freno.