Summary

  • RFC 1011 separó la especificación de cada protocolo de su categoría, comentarios, dependencias y contacto, para coordinar un sistema técnico amplio y cambiante.
  • «Obligatorio» expresaba lo que los hosts debían implementar; no revelaba qué código estaba instalado o en ejecución en cada máquina.

Una lista con fecha de caducidad

El memorando de Joyce Reynolds y Jon Postel, publicado en mayo de 1987, se tituló Official Internet Protocols. Se presentaba como un informe de estado: identificaba los documentos que especificaban los protocolos usados en Internet y añadía comentarios sobre revisiones o cambios previstos. Era más parecido a un mapa fechado de un sistema en movimiento que a un manual que describiese el estado de cada máquina.

El propio documento hacía visible ese límite. Pedía usar una copia fechada dentro de los tres meses anteriores. Cada entrada podía señalar la especificación, indicar dependencias, mencionar problemas de implementación y ofrecer una persona de contacto. Así, el lector podía averiguar no solo qué texto describía un protocolo, sino también dónde quedaban asuntos abiertos o dónde debía continuar la coordinación.

Cada protocolo recibía una de cinco categorías. «Obligatorio» significaba que todos los hosts debían implementarlo. «Recomendado» alentaba su implementación. «Electivo» dejaba la elección a cada host. «Experimental» limitaba la implementación a experimentos coordinados. «Ninguno» indicaba que la entrada no era un protocolo. Eran expectativas distintas, no cinco mediciones de lo que hacían las máquinas.

La categoría no instalaba el programa

Las filas muestran la diferencia. IP era obligatorio; TCP y UDP, recomendados. La entrada «Graphics Protocol» era electiva, pero su comentario señalaba que no se conocían implementaciones activas. El comentario no borraba la entrada, y la categoría tampoco hacía aparecer software. Los autores registraron tanto una clasificación como el límite de lo que sabían.

La pareja es importante. Un catálogo puede ser referencia autorizada sobre la categoría asignada a una especificación y, aun así, no certificar el comportamiento de todos los hosts. «Obligatorio» es una expectativa de compatibilidad. Para describir la realidad operativa hacen falta implementaciones y observación. RFC 1011 no ofrecía un censo completo de hosts, un inventario de versiones instaladas ni un recibo de pruebas que demostrara que todos ejecutaban correctamente cada protocolo obligatorio.

La especificación y la implementación convergían con el tiempo

RFC 1011 pertenecía a una serie de publicaciones periódicas. Los informes anteriores se sustituían y los posteriores revisaban la lista. En abril de 1989, RFC 1100 describió el proceso más amplio de normalización: cualquiera podía proponer un protocolo, los grupos técnicos aportaban recomendaciones y la política general era esperar experiencia de implementación antes de declararlo estándar oficial. También explicaba que un número RFC no se reutilizaba, aunque un protocolo podía mejorarse y documentarse en RFC posteriores.

Eso no volvía irrelevantes las normas. Una especificación común permitía que equipos independientes persiguieran el mismo comportamiento. Pero entre la propuesta y el servicio había más que la publicación: implementar una versión, probarla con otros sistemas, corregirla según la experiencia y adoptarla. Los requisitos para hosts de 1989 concretaban muchas expectativas para hosts de Internet de propósito general. Aun así, el lenguaje normativo describía qué debía hacer un host conforme; no demostraba que todas las máquinas desplegadas lo cumplieran.

La periodicidad de la lista tenía sentido. Un informe trimestral ayudaba a operadores e implementadores a encontrar el documento vigente, pero la fecha formaba parte de su validez. Una fila correcta al publicarse podía quedar anticuada al cambiar especificaciones, comentarios y práctica. La advertencia contra el uso de una copia vieja reconocía que la coordinación necesitaba mantenimiento.

Un registro útil, no una red en ejecución

Conviene leer RFC 1011 como una herramienta de coordinación. Hacía legibles los estados, vinculaba las entradas con documentos y contactos, y exponía incertidumbres en lugar de esconderlas. Esas funciones podían influir en decisiones: una recomendación o un requisito no eran palabras vacías. Pero el informe no entraba en cada host para convertir la decisión en código operativo.

La frontera sigue siendo útil para leer la historia de Internet. Un número de documento no es una implementación. Una categoría de estándar no es una captura de paquetes. Una recomendación no es un recuento de despliegues. Las reglas comunes reducen el conjunto de opciones compatibles, pero la red existe mediante los sistemas que los operadores eligen ejecutar y mantener interoperables.

Fuentes