Resumen

  • El principio original respondía a especificaciones imperfectas: emitir una forma cuidada y aceptar un defecto técnico si el significado seguía claro.
  • La tolerancia silenciosa privó al emisor de una señal de corrección. El desvío desplegado se volvió una dependencia que los nuevos programas debían imitar.
  • La reparación moderna conserva resiliencia, pero usa errores definidos, mantenimiento activo y pruebas constantes de extensibilidad.

La ambigüedad vino primero

RFC 760 admitía que incluso una especificación explícita podía tener interpretaciones distintas. En una red joven, construida por talleres heterogéneos, esperar un texto perfecto habría detenido la experiencia. Si el sentido era inequívoco, el receptor podía mantener viva la conversación.

RFC 793 redujo el pacto a la máxima de TCP: actuar con prudencia y aceptar con liberalidad. Separada de su contexto provisional, la frase pasó a parecer una ley universal.

Resistir una entrada no es inventarla

RFC 1122 distinguía tareas que suelen confundirse. El software debe sobrevivir a entradas hostiles o improbables; los campos enumerados deben dejar espacio a códigos futuros; el emisor evita funciones legales pero oscuras que exponen fallos ajenos; los errores se registran.

Nada de eso autoriza a adivinar semántica. Dos receptores permisivos pueden entender de manera distinta el mismo mensaje defectuoso. RFC 1958 mantuvo la tolerancia en la arquitectura, pero con ella el receptor heredaba el coste de una ambigüedad que no produjo.

El fallo aceptado adquirió usuarios

Si no hay rechazo ni evidencia visible, el emisor repite el defecto. Otros receptores incorporan la excepción porque romper tráfico instalado parece un fallo propio. La anomalía entra en pruebas y operación.

La población desplegada reemplaza entonces al texto como prueba de conformidad. Una implementación nueva copia el bug o queda fuera. El emisor controla la salida incorrecta; todos los pares futuros pagan la compatibilidad.

BGP definió el daño

RFC 7606 demuestra que recuperarse no exige adivinar. Para atributos BGP malformados asigna acciones concretas: tratar rutas como retiradas, descartar sólo ciertos atributos o aplicar una medida mayor cuando no puede analizarse con seguridad. También exige diagnóstico del UPDATE defectuoso.

El receptor limita el daño y conserva prueba. Puede haber pérdida de alcance, pero su causa y frontera son revisables.

TLS ejercitó el espacio vacío

Una extensión escrita pero nunca usada puede desaparecer. El software intolerante prospera hasta que la primera novedad real llega a producción.

RFC 8701 reserva valores GREASE y hace que clientes TLS los envíen. Los servidores deben demostrar continuamente que lo desconocido no rompe la negociación. RFC 9170 amplía la regla: sólo el uso activo mantiene viable una extensión; la declaración sin ejercicio se osifica.

Mantener pasó a ser parte del protocolo

RFC 9413 conserva la defensa frente a fallos y ataques, pero rechaza que aceptar lo inesperado sea siempre correcto. La tolerancia acumulada produce compatibilidad bug por bug, bloquea cambios y encarece nuevas implementaciones.

Propone mantenimiento activo: informar diferencias, actualizar especificación y código, definir errores, hacer visibles los fallos cuando sea seguro y retirar los apaños temporales. La exclusión puede proteger la interoperabilidad futura, pero debe ser deliberada, documentada y acompañada de migración.

El texto es informativo y su sección de aplicabilidad presupone software actualizable. Un dispositivo inmóvil puede requerir una excepción acotada; esa limitación no convierte el apaño en norma eterna.

Fuentes y límites

La secuencia consta en RFC 760, RFC 793, RFC 1122, RFC 1958, RFC 7606, RFC 8701, RFC 9170 y RFC 9413. Documenta reglas y casos, no uniformidad mundial. La conclusión es estrecha: tolerar daño limitado sin esconder ambigüedad heredable.