Resumen

  • RFC 2360 apareció en junio de 1998 como BCP 22, una guía para quienes redactaban estándares. Prometía aumentar la probabilidad de interoperar, no certificarla.
  • La guía exigía describir qué ocurría con datos fuera de límites, opciones desconocidas y recursos agotados: recuperar, descartar o activar un error eran decisiones distintas, y cada una debía indicar el estado resultante.
  • Las palabras normativas y los formatos formales marcaban obligaciones y sintaxis; los diagramas, tablas y máquinas de estados mostraban otras dimensiones. Ninguno sustituía a la implementación ni a la prueba observada.

Un mensaje inválido puede producir dos verdades válidas

El caso más revelador de RFC 2360 no era una disputa sobre estilo. Era una actualización de encaminamiento cuyo contador declaraba menos tuplas que los bytes presentes. Un receptor podía ignorar el sobrante. Otro podía recuperarlo como rutas adicionales. Otro podía rechazar todo porque el mensaje admitía interpretaciones incompatibles.

En los tres casos el analizador había entendido los campos. La divergencia nacía al decidir qué realidad conservar.

Gregor D. Scott editó la guía a partir de experiencia de especificaciones exitosas y fallidas. El texto no enumeraba un inventario exhaustivo de incidentes, por lo que no autoriza a atribuirle disputas concretas. Sí afirmaba algo verificable: la falta de claridad era una barrera reconocida, aunque una redacción impecable tampoco garantizaba que programas independientes coincidieran.

Ese límite separaba autoridad documental de operación. Una comunidad podía publicar el comportamiento que esperaba. No podía ejecutar el código de cada fabricante ni observar por anticipado todas las presiones de memoria, tiempos y combinaciones de opciones.

Descartar el mensaje no decide qué sobrevive

La sección sobre conducta fuera de especificación partía de una constatación: los implementadores solían discrepar en la respuesta. El documento podía ordenar descarte, procedimiento de error o recuperación parcial. No existía una respuesta universalmente correcta; sí existía la obligación de no dejarla a la intuición local.

Si una trama se descarta como si nunca hubiera llegado, los temporizadores y la vecindad quizá continúen. Si el mismo defecto demuestra pérdida de sincronía, la asociación puede reiniciarse. Ambos receptores han rechazado los datos. Solo uno ha destruido el contexto compartido.

Los límites de escala también necesitaban semántica. Al llenarse una cola o agotarse un identificador, ¿se protege el trabajo ya aceptado o se sacrifica para admitir lo nuevo? ¿Se envía un error o se guarda silencio? ¿El par puede distinguir rechazo de pérdida? Una política privada de supervivencia puede dejar a dos nodos con historias incompatibles.

Por eso RFC 2360 desconfiaba de invocar sin detalle la regla de aceptar con liberalidad y enviar con prudencia. La tolerancia debía tener una frontera. En protocolos de encaminamiento, rescatar información ambigua podía propagar un error mucho más lejos que el paquete que lo contenía.

El formato ocupaba espacio; el estado ocupaba tiempo

Una figura de bits responde dónde está cada cosa. La máquina de estados explica en qué momento tiene efecto. RFC 2360 aconsejaba nombrar estados, variables, eventos, transiciones y acciones, y conservar el orden de acciones cuando modificaba el resultado.

Un mensaje puede abrir una relación en un estado y ser ilegal en otro. Un tiempo vencido puede ordenar reintento mientras se espera respuesta y resultar irrelevante tras el cierre. Una secuencia invertida puede mostrar al otro extremo un estado intermedio distinto aunque el paquete final sea idéntico.

La guía no convertía el diagrama en un oráculo. Lo consideraba auxiliar; el texto detallado prevalecía si había conflicto. Esa jerarquía obligaba a señalar cuál descripción de una exigencia era vinculante cuando el documento la repetía.

Las tablas resumen reducían otra clase de error: omitir una función obligatoria en cientos de páginas. Podían listar lo obligatorio, opcional y prohibido y remitir al apartado correspondiente. Ayudaban a comprobar cobertura; no demostraban conformidad.

La mayúscula daba fuerza, no contenido

RFC 2119 había estabilizado MUST, SHOULD y MAY. RFC 2360 pedía no alterar sus definiciones, porque servían para destacar exigencias de interoperabilidad y límites contra conducta dañina.

Sin embargo, “MUST rechazar” no contesta qué unidad se rechaza, en qué momento, con qué señal ni hacia qué estado. Tampoco dice si un número de secuencia avanza o si una vecindad sigue siendo utilizable. Una obligación fuerte puede seguir siendo incompleta.

Una gramática formal tiene un problema paralelo. Define formas válidas, pero no quién está autorizado a producirlas, qué efecto debe seguir ni cómo responder cuando falta un recurso. Una notación procesable por máquina no reemplaza la descripción legible del comportamiento.

Lo opcional reaparece cuando dos extremos se encuentran

Una opción puede aplazar una decisión del grupo de trabajo, pero el par tendrá que resolverla en ejecución. RFC 2360 exigía una necesidad real, valor predeterminado, efecto de usarla y omitirla, y análisis de combinaciones mutuamente excluyentes.

La ausencia de una opción no debía destruir la interoperabilidad básica. Eso requería descubrimiento de capacidades y un retroceso conocido. En seguridad, un valor predeterminado débil podía cambiar protección por comodidad sin que la pérdida quedara visible.

RFC 6709 estudiaría después el riesgo de extensiones con más amplitud. Sirve como contraste posterior, no como prueba de que BCP 22 causó aquella obra. La aportación de 1998 fue hacer explícita la factura que la palabra “opcional” deja para el encuentro entre implementaciones.

La razón de una regla también envejece

RFC 2360 pedía historial de cambios, diferencias entre versiones y razones de decisiones difíciles. Conservar el porqué evitaba que un futuro implementador eligiera un atajo más sencillo sin saber qué incompatibilidad había obligado a descartarlo.

No era una prohibición de revisar el acuerdo. Era una exigencia de hacerlo con nueva evidencia. Cuando desaparece el contexto, una barrera protectora parece ceremonia; cuando queda registrada, puede ser cuestionada por experiencia, pruebas o daño observado.

Seguridad, gestión, escalabilidad, estabilidad, internacionalización y asignación de números cumplían la misma función: sacar a la vista dependencias que el formato no contiene. Quién administra el espacio común, qué topología no converge, qué recurso es finito y qué puede observar un operador son partes del sistema.

La especificación no era la ejecución

La primacía del código en funcionamiento de Lu Heng permite leer la guía sin inflarla. La especificación declara una conducta. Una implementación revela una interpretación. Una prueba entre versiones concretas observa un perímetro. La operación muestra el resultado bajo carga e inputs reales.

Una tabla completa no prueba que el programa la siga. Dos productos compatibles entre sí pueden apartarse del texto. Una batería nominal no observa agotamiento. Una red estable hoy no demuestra que toda combinación facultativa sea segura.

El mínimo común necesita, por tanto, más que sintaxis: debe fijar las decisiones que cambian estado compartido y dejar que implementación y medición confirmen el resto. RFC 2360 hizo histórica esa frontera al reconocer que el protocolo continúa después del último bit bien dibujado.

Fuentes y límites

El estado editorial y la guía están en la ficha de RFC 2360 y su texto completo. El proceso procede de RFC 2026, los términos normativos de RFC 2119, el marco arquitectónico de RFC 1958 y las instrucciones de autor vigentes entonces de RFC 2223. Entre los ejemplos citados están RFC 1122 y RFC 2328; RFC 6709 aporta una comparación posterior. Los límites de inferencia siguen a Lu Heng sobre Running-Code Primacy, Minimum Initial Specification y Reality Layers. Estas fuentes no miden conformidad actual, no identifican un incidente para cada recomendación y no garantizan que documentos posteriores aplicaran toda la guía.