Resumen

  • RFC 1280 era una fotografía de coordinación, no un inventario en tiempo real: pedía consultar la edición vigente y prohibía usar esta copia después del 31 de julio de 1992.
  • STATE describía la madurez de la normalización; STATUS, el nivel de exigencia para implementar. Ninguna etiqueta demostraba por sí sola despliegue ni funcionamiento.

Una lista puede resultar engañosa justo porque es útil. Quien debía saber dónde encajaba un protocolo necesitaba una referencia compartida, no una colección de RFC aisladas. RFC 1280 intentó ofrecerla al reunir protocolos, explicar etapas de normalización y asignar niveles de exigencia. También limitó su propia autoridad: la edición de marzo de 1992 se pensaba publicar aproximadamente cada trimestre y dejaba de ser utilizable después de julio.

La fecha no anunciaba que todo protocolo cambiaría el 1 de agosto. Delimitaba cuánto podía afirmar ese ejemplar. La IAB remitía a una copia actualizada del Network Information Center o de IANA y a las notas de cambios. En septiembre, RFC 1360 sustituyó a RFC 1280. Una lista oficial podía registrar correctamente una decisión en su fecha y, aun así, estar desfasada cuando llegara la siguiente decisión.

El vocabulario separaba dos coordenadas. STATE colocaba la especificación en su evolución: estándar, borrador de estándar, propuesta, experimental, informativa o histórica. STATUS decía qué se esperaba de determinadas clases de sistemas: requerido, recomendado, electivo, de uso limitado o no recomendado. Una propuesta podía ser electiva; un documento informativo podía ser recomendado. Madurez y exigencia no eran sinónimos ni una única escala.

Tampoco eran un censo de máquinas. RFC 1280 señalaba que algunos protocolos de proveedores habían alcanzado una implementación amplia sin recomendación de IESG ni ratificación de IAB. A la vez, “experimental” permitía documentar investigación sin recomendar su uso operativo. La publicación de una especificación no probaba que estuviera desplegada, y su lugar en el proceso no medía su popularidad. Para eso hacían falta otros registros: implementaciones independientes, interoperabilidad y experiencia de operación.

Las referencias auxiliares tampoco se actualizaban a la vez. Assigned Numbers, Gateway Requirements y Host Requirements tenían calendarios distintos; si discrepaban, prevalecía el documento más reciente. RFC 1280 organizaba las referencias y señalaba cuál era la RFC vigente para un protocolo, pero no sincronizaba todas sus fuentes. RFC 1310 explicaba el proceso y asignaba a la lista periódica la función de registro autorizado. Esa autoridad venía con fecha y alcance: una fila histórica no demuestra lo que hoy hace un protocolo, lo que instaló un operador ni si respondió un servicio.

Fuentes: RFC 1280; RFC 1310; RFC 1360.