Cuando dos programas creados por empresas distintas se encuentran en Internet, basta con que interpreten de manera diferente una sola letra de la especificación para que la comunicación se interrumpa con facilidad. Sin embargo, en los primeros tiempos de Internet, la red logró mantenerse conectada pese a esas pequeñas diferencias. La «ley de Postel» (Postel's Law) suele citarse como explicación de ese logro.
En pocas palabras, la ley de Postel es un principio de diseño de comunicaciones que dice: «Al enviar, cíñete estrictamente a la especificación. Al recibir, sé tolerante siempre que puedas interpretar lo que recibes». En los documentos oficiales también se denomina «principio de robustez» (Robustness Principle).
En este artículo veremos de dónde surgió la ley de Postel, por qué Internet la necesitó, cómo se manifiesta en la vida cotidiana y en el desarrollo de software, y por qué se la critica hoy en día.
Entender la ley de Postel
¿De dónde surgió la ley de Postel?
Esta ley lleva el nombre del informático estadounidense Jonathan B. Postel (1943–1998). Trabajó en el Instituto de Ciencias de la Información de la Universidad del Sur de California (USC ISI), donde se encargó desde 1969 hasta su muerte de editar la serie RFC, que reúne documentos sobre los estándares de Internet. También desempeñó un papel central en la IANA, encargada de gestionar direcciones y números.
En el mes 1 de 1980, las especificaciones de Internet que preparó Postel, RFC 760 (Protocolo de Internet) y RFC 761 (Protocolo de Control de Transmisión), incluyeron el principio de robustez. En el borrador del RFC 760 figuraba una frase parecida. La formulación exacta, «Sé conservador al enviar y tolerante al recibir» (be conservative in what you do, be liberal in what you accept from others), apareció en el RFC 761. La frase se mantuvo en el estándar TCP de 1981, el RFC 793, y más tarde se popularizó con el nombre de «ley de Postel».
Postel consideraba que, por muy detallada que fuera una especificación, distintas personas podían interpretarla de maneras diferentes. Por eso recomendaba que el emisor produjera datos bien formados y ajustados al estándar, y que el receptor pasara por alto los pequeños errores de formato cuando el significado estuviera claro.
¿Por qué ser estricto al enviar y tolerante al recibir?
Internet no es una red cerrada que utiliza únicamente equipos de una sola empresa. Distintos sistemas operativos, lenguajes y versiones de programas tienen que comunicarse siguiendo el mismo protocolo. Si ambos extremos rechazan cualquier diferencia por pequeña que sea, basta una leve discrepancia de interpretación para interrumpir la conexión.
(1) Rigor del emisor
Si el emisor respeta el formato y la longitud e incluye todos los campos obligatorios tal como indica la especificación, al receptor le resulta más fácil interpretar los datos, sea cual sea su implementación. Si el emisor amplía la especificación por conveniencia propia, el receptor tiene que admitir todas esas variantes.
(2) Tolerancia del receptor
Si el significado de los datos está claro, un problema menor de formato no basta para descartarlos por completo. Así, distintas implementaciones pueden coexistir durante un tiempo.
(3) Prioridad de la interoperabilidad
Se da prioridad a que la comunicación funcione, aun cuando la coincidencia sea imperfecta. En un entorno como el de los primeros tiempos de Internet, con implementaciones muy dispares, esa tolerancia facilitó el crecimiento de la red.
(4) Reconocimiento de las limitaciones de la especificación
Se parte de que el documento puede contener lagunas o expresiones ambiguas. El equilibrio consiste en dar al receptor cierto margen y en pedir al emisor que actúe con más cuidado, sin depender de ese margen.
La ley de Postel en la vida cotidiana y en el desarrollo de software
Este principio también se observa fuera de las redes. Un navegador que muestra una página pese a pequeños errores en el HTML o un programa de correo electrónico que intenta abrir y mostrar un mensaje con un formato incorrecto siguen una lógica parecida.
En las interfaces de software también se toman decisiones similares.
- Interfaz pública (Public API). Las solicitudes y respuestas que se envían al exterior usan únicamente los formatos documentados y evitan introducir campos experimentales sin avisar.
- Validación de entradas (Input Validation). Se comprueban rigurosamente los valores obligatorios y los peligrosos, y el equipo acuerda de antemano si se admitirán pequeñas variaciones de representación que conserven el mismo significado.
- Compatibilidad con versiones anteriores (Backward Compatibility). Si las versiones nuevas pueden leer los datos antiguos, se evita tener que rehacer todo el sistema de golpe.
- Registros y mensajes de error (Clear Errors). Incluso cuando se admiten irregularidades al recibir datos, conviene registrar qué se apartó de la especificación para poder corregirla más adelante.
En pocas palabras, se traslada al diálogo entre máquinas una actitud cotidiana: «Cuando hablo, me expreso con claridad. Cuando escucho, procuro entender lo que la otra persona quiere decir».
¿Por qué se revisa hoy esta ley?
La ley de Postel contribuyó enormemente al crecimiento de Internet, aunque con el tiempo también se hicieron visibles sus efectos adversos. Si el receptor es demasiado tolerante, pueden acumularse interpretaciones ambiguas y es más fácil que surjan ataques que aprovechen esas ambigüedades. Además, si se aceptan en silencio formatos incorrectos, la propia especificación puede quedar sin corregir durante mucho tiempo.
En debates recientes sobre los estándares de Internet se ha señalado que «la tolerancia por sí sola no garantiza la interoperabilidad a largo plazo». Martin Thomson y otros han advertido que, si se da por hecho que la especificación es fija y se insiste únicamente en la tolerancia, la ambigüedad puede acabar consolidándose como si fuera parte del estándar.
Por eso, la práctica actual tiende a mantener el principio y afinar el equilibrio con el que se aplica.
- Rigor al enviar (Strict Send). Los datos salientes se preparan de modo que cumplan la especificación y superen las comprobaciones del validador.
- Prudencia al recibir (Careful Accept). La documentación y las pruebas delimitan con claridad qué variantes se admiten. Las demás se rechazan.
- Actualización de las especificaciones (Evolve Specs). Las diferencias que aparecen con frecuencia en la práctica se hacen explícitas y sirven para ir corrigiendo las especificaciones y los ejemplos.
- Seguridad ante todo (Security First). Primero se comprueba si la tolerancia amplía la superficie de ataque.
La ley de Postel recoge una idea de los primeros tiempos de Internet: lograr que distintas implementaciones coexistieran tenía prioridad sobre alcanzar una «especificación perfecta». Al mismo tiempo, advierte que la tolerancia puede aumentar la ambigüedad y el riesgo.
Expresarse con mayor claridad al enviar y procurar entender lo que se recibe con límites bien definidos es el primer paso para crear sistemas que se comuniquen entre sí.
