Resumen

  • La RFC 1 repartía el trabajo: BBN había especificado el software de los IMP, mientras que los grupos de hosts debían acordar el software que permitiría a sus ordenadores usar la red.
  • Steve Crocker calificó el contenido de provisional y esperaba respuestas. La RFC 3 explicó después que un texto publicado podía parecer autoritativo por el mero hecho de estar escrito, justo lo que la serie quería evitar al abrir espacio a ideas todavía discutibles.
  • Los cambios de la RFC 6, la implementación GORDO de UCLA descrita en la RFC 11 y las revisiones que recoge la RFC 33 muestran un proceso en marcha. No prueban que todos los hosts adoptaran la RFC 1 sin modificarla.

El acuerdo pendiente estaba por encima de la red de paquetes

La primera red ARPA tenía una división técnica clara. Bolt, Beranek and Newman había especificado los IMP, las máquinas que transportaban mensajes entre los sitios. Los ordenadores conectados todavía necesitaban convenciones de software para abrir conexiones, identificar enlaces y decidir cómo procesar los datos recibidos desde otro host.

Fechada el 7 de abril de 1969, la RFC 1 de Steve Crocker llevó ese problema entre hosts a un documento común. Resumía el formato de los mensajes de los IMP y bosquejaba software de host para solicitudes de conexión, sesiones parecidas a un teletipo, transferencias de archivos grandes, comprobación de errores e interacción remota. También consideraba una interfaz local que respondiera de inmediato a algunas acciones del terminal sin enviar cada pulsación por la red.

No era una sola decisión tomada en una sola capa. El reenvío de los IMP y el comportamiento de los sistemas operativos de los hosts implicaban responsabilidades y fallos distintos. Un mensaje podía llegar al IMP correcto aunque los dos sistemas aún no supieran cómo abrir una sesión o interpretar lo que recibían.

La introducción de Crocker deja claro el estado de la propuesta: el grupo había alcanzado algunos acuerdos tentativos, tenía preguntas abiertas y casi nada de lo expuesto era definitivo. El valor del documento incluye conservar esa incertidumbre. Leerlo como una especificación completa borraría la etapa de trabajo que registra.

Lo que la primera nota puso sobre la mesa

La RFC 1 organizaba la comunicación mediante enlaces lógicos entre pares de hosts. Planteaba reservar un enlace para el control entre sistemas operativos y utilizar los demás para sesiones de usuario. Una conexión podía comportarse como una línea de teletipo; otra, paralela y pensada para archivos, permitiría transferir volúmenes mayores sin el almacenamiento en búfer ni las interrupciones propias del terminal.

El texto también buscaba que el trabajo remoto resultara ágil pese al retardo de la red. Una propuesta consistía en enviar una pequeña interfaz local escrita en un lenguaje llamado entonces DEL para atender junto al usuario las respuestas rutinarias del terminal. La idea seguía en discusión: la nota no dice que ya estuviera desplegada en todos los hosts.

Los experimentos iniciales tenían el mismo alcance limitado. Crocker describió el trabajo del SRI en un sistema de consulta y una interfaz DEL, además de planes de uso con UCLA y Utah. Eso permite ver qué intentaban construir los participantes. No es un inventario de instalaciones por sitio ni demuestra que los cuatro hosts iniciales hubieran implementado cada propuesta.

La primera RFC no fue una orden de un organismo de normalización. Ofreció un lugar para exponer decisiones de diseño, pedir correcciones y dar a un grupo distribuido entre varios centros algo concreto que examinar.

La serie facilitó documentar el desacuerdo

Dos días después de la RFC 1, Bill Duvall escribió la RFC 2, también titulada «Host Software». La RFC 3 fijó algunas convenciones: cualquiera en cualquier sitio podía producir una nota; se priorizaba la oportunidad sobre el pulido; el título no tenía por qué ser único. Bill Duvall, en SRI, asignaba los números de serie.

La RFC 3 también señaló un problema conocido en la gobernanza técnica: el lector tiende a conceder autoridad a una afirmación escrita y publicada. El formato flexible buscaba promover el intercambio de ideas todavía no autoritativas. El número permitía localizar la nota; no resolvía la cuestión que esta planteaba.

No era un proceso de normalización ya terminado a escala reducida. Las primeras notas combinaban propuestas, preguntas, detalles de implementación y solicitudes de respuesta. Su utilidad residía en hacer visible el razonamiento técnico entre sitios que debían interoperar y, a la vez, mantener ordenadores y sistemas operativos distintos.

Revisar e implementar son pruebas diferentes

La RFC 6, relato de Crocker sobre una conversación con Bob Kahn el 10 de abril, registra un cambio en el campo de enlace Host–IMP: pasó a cinco bits y sumó un bit para indicar conversión. El detalle es pequeño, pero su fecha importa. Apenas unos días después de la RFC 1, uno de sus elementos seguía bajo discusión.

En agosto, la RFC 11 de Gerard Deloche describió los procedimientos entre hosts y su implementación en GORDO, el sistema de tiempo compartido de UCLA para SDS Sigma 7. Especificó tipos de conexión, mensajes de control, sumas de comprobación, búferes y programas que conectaban a los usuarios con la interfaz de los IMP. La RFC 13, del mismo mes, remitió a la RFC 11 y propuso un mensaje de longitud cero para marcar el fin de una transferencia de archivos por una conexión auxiliar.

Esos documentos muestran ideas más concretas dentro de una implementación identificable y una propuesta posterior para resolver una necesidad específica. No demuestran que todos los hosts usaran los procedimientos de GORDO ni que la red hubiera dejado de cambiar. Una implementación funcional es una prueba más sólida de operación en un sitio que una propuesta por sí sola, pero no revela cuántos sitios la adoptaron.

La RFC 33 explicita la diferencia. En febrero de 1970 informó de muchos cambios respecto del protocolo anterior de la RFC 11, los vinculó a una reunión de red en diciembre y advirtió que el documento adjunto aún no bastaba para escribir un Network Control Program. Solicitaba respuestas. Había conexiones operativas y uso real, pero el protocolo de host seguía en revisión y documentación.

Por qué importa la RFC 1 sin ser la última palabra

La importancia histórica de la RFC 1 no es que cada campo o procedimiento quedara fijado para siempre. Importa porque permitió discutir un problema de diseño común antes de que todos los hosts tuvieran una implementación asentada. Asignó responsabilidades, propuso opciones y dejó sus dudas a la vista.

Ese logro es distinto de desplegar un protocolo. Un texto puede encuadrar un problema; una revisión puede acotar el desacuerdo; el código puede demostrar que un sistema funciona; las pruebas repetidas pueden mostrar que sistemas independientes interpretan igual los mensajes. Son fases relacionadas, pero ninguna certifica automáticamente la siguiente.

El archivo temprano permite así una explicación más precisa de cómo empezó la coordinación. BBN especificó la capa de los IMP. Los grupos de hosts desarrollaron el software superior. Las RFC proporcionaron una superficie de discusión numerada y transportable. Las implementaciones y las notas posteriores documentaron lo probado y lo modificado. El primer número abrió ese proceso; no lo concluyó.

Fuentes

La RFC 1 es la fuente primaria de la propuesta provisional de Crocker. La RFC 2 registra la nota de Bill Duvall titulada «Host Software»; la RFC 3 explica las primeras convenciones documentales. La RFC 6 describe una conversación posterior sobre la interfaz Host–IMP. La RFC 11 de Deloche detalla los procedimientos y su implementación en GORDO; la RFC 13 de Cerf propone un marcador de fin para las transferencias auxiliares. La RFC 33 de Crocker y sus colegas registra cambios posteriores y dudas aún abiertas. El índice RFC 170, de 1971, cataloga las primeras notas con sus fechas.