Resumen

  • RFC 880 registraba por separado el estatus de un protocolo, su especificación, los problemas conocidos, las referencias, las dependencias y una persona de contacto.
  • La propia lista demuestra que esas columnas no eran equivalentes: TCP era recomendado con defectos documentales abiertos, TFTP era electivo pero se usaba y GGP era experimental aunque operaba en los gateways centrales.
  • La normalización posterior distinguió madurez y nivel de exigencia; el resumen periódico acabó sustituido por una lista en línea, que seguía sin medir por sí sola el código en ejecución.

La palabra «electivo» podía leerse como permiso para no instalar. No decía cuántos administradores ya habían instalado el protocolo, ni si lo habían habilitado, ni si dos versiones podían interoperar. La RFC 880, Official Protocols, conservó esa modestia semántica.

El documento de octubre de 1983 no era una vitrina de tecnologías terminadas. Era un inventario comentado: señalaba qué texto definía cada protocolo, qué esperaba la comunidad de los hosts, qué dependencias existían, quién podía responder y qué defectos o desviaciones ya se conocían.

No había un solo libro oficial

RFC 880 partía, «en primera aproximación», del Internet Protocol Transition Workbook de marzo de 1982. Inmediatamente añadía las excepciones. Había protocolos en uso que no aparecían en el volumen. Otros habían sido revisados. El correo, Telnet y las guías de implementación estaban repartidos en publicaciones distintas; parte del material seguía en el manual ARPANET de 1978.

Su predecesora, RFC 840, había usado la misma matriz en abril. Seis meses después quedaba obsoleta por RFC 880. El reemplazo no invalidaba de golpe todas las máquinas; actualizaba la vista editorial desde la que se coordinaban documentos y expectativas.

Cada entrada separaba STATUS, SPECIFICATION, COMMENTS, OTHER REFERENCES, DEPENDENCIES y CONTACT. Si un campo cambiaba, los demás no tenían por qué cambiar en el mismo instante. Ésa era la protección contra una etiqueta total.

El estatus marcaba una regla de adopción

Required exigía implementación en todos los hosts. Recommended la aconsejaba. Elective permitía elegir. Experimental limitaba la implementación a participantes coordinados. None indicaba que la entrada no era un protocolo.

IP e ICMP eran Required; UDP y TCP, Recommended; TFTP, Elective; EGP y GGP, Experimental. El modelo Catenet llevaba None. La clasificación no era una puntuación de seguridad o de calidad. Contestaba qué relación de adopción proponía el catálogo.

Incluso Required seguía siendo una declaración. Para demostrar que un host cumplía había que mirar su implementación. Para demostrar que funcionaba había que observar el camino y la aplicación.

Un protocolo recomendado podía conservar ambigüedades

La entrada de TCP remitía a RFC 793 y lo marcaba Recommended. Después registraba una larga lista de trabajo pendiente. Muchas correcciones eran «document bugs», no necesariamente errores en la intención del protocolo. La diferencia importaba porque dos programadores podían resolver un texto ambiguo de maneras incompatibles.

Push todavía sonaba a marca de registro aunque no lo fuera. MSS necesitaba una explicación mejor. Los servidores en escucha, las conexiones ociosas, los datos en cola durante el cierre, los segmentos fuera de orden y el temporizador del usuario requerían precisión adicional.

La recomendación no desmentía esos comentarios. Los mantenía junto al estatus para que nadie confundiera coordinación con perfección. Copiar sólo la celda verde habría sido una lectura menos fiel del documento oficial.

Experimental podía describir código central

EGP era Experimental y estaba en desarrollo. GGP también era Experimental, pero el comentario decía que entonces se utilizaba en los gateways del núcleo. La lista no proporcionaba un recuento de routers ni un resultado de interoperabilidad. Sí demostraba que «experimental» no equivalía a «ausente de producción».

Stream Protocol mostraba un desfase distinto: la implementación había evolucionado y podía no corresponder a la especificación. El código que corría no certificaba el texto citado.

TFTP, en cambio, era Elective y se describía como usado en varias redes locales. El estatus permitía la elección; el comentario observaba alguna adopción. Ninguno de los dos campos sustituía al otro.

Las opciones Telnet no cabían en una sola afirmación de soporte

RFC 880 incluyó una tabla con el documento de cada opción, su presencia en el nuevo manual Telnet, su existencia en el antiguo manual ARPANET y una columna USE. Echo, Binary Transmission, Suppress Go Ahead y otras opciones actualizadas aparecían como frecuentes. Muchas alternativas antiguas no tenían uso general.

La familia de opciones era Elective. Aun así, la lista no infería la implementación de cada función. «Habla Telnet» era una descripción demasiado amplia para saber qué negociaría un par concreto.

La observación de uso era necesariamente limitada y fechada. Su valor consistía en reconocer un límite: ni un número ni una referencia bibliográfica podían observar por sí solos la rama de código activa.

Dependencia y contacto completaban el alcance

TFTP dependía de UDP; SMTP y Telnet, de TCP; los protocolos de gateway, de IP. Una entrada superior sólo podía ejecutarse si su cadena inferior existía. El catálogo no confundía la obligación de una capa con la presencia de toda la aplicación.

Los contactos daban un cauce a la coordinación experimental y a las dudas de interpretación. No convertían a una persona en propietaria universal del protocolo. Mostraban que el mantenimiento seguía necesitando actores identificables.

La RFC 991 continuó esa serie en 1986 y se definió como informe oficial de estatus. Las sustituciones sucesivas hicieron visible el tiempo del catálogo.

La madurez y la exigencia se convirtieron en dos dimensiones formales

La RFC 1200 separó en 1991 el STATE de normalización —Standard, Draft Standard, Proposed Standard, Experimental, Informational, Historic— del STATUS de exigencia —Required, Recommended, Elective, Limited Use, Not Recommended—.

La RFC 2026 formalizó la evolución de las especificaciones y la aplicabilidad. La RFC 6410 redujo más tarde la pista de estándares a dos niveles de madurez. Ninguna decisión procesal contó instalaciones o paquetes.

En 2013, la RFC 7100 retiró el último resumen periódico y STD 1 porque habían quedado desactualizados y la lista en línea del RFC Editor ocupaba su lugar. Cambiar papel reemplazable por base de datos mejoró la actualización; no convirtió el registro en telemetría.

Fuentes y límites

El análisis se apoya en RFC 840, RFC 880, RFC 991, RFC 1200, RFC 2026, RFC 6410 y RFC 7100. Estas fuentes documentan el catálogo y el proceso, no la cuota de despliegue actual, la conformidad de un producto, la seguridad presente, un incidente o la política de un operador.