Sé estricto en lo que haces y flexbile en lo que aceptas de otros.
El Principio de Robustez fue descrito por Jon Postel en el documento definitiorio del Transmission Control Protocol (TCP) de 1981, RFC 793 (documento en inglés), en una sección propia con este enunciado (traducido del original):
2.10. Principio de Robustez
Las implementaciones de TCP deben seguir el principio general de robustez: ser estrictas en lo que hacen y flexbiles en lo que aceptan.
El objetivo de este principio es facilitar la interoperación de distintos sistemas cuando estos son contruidos por distintos grupos basándose todos ellos en una especificación común.
Dado que dicha especificación puede no ser exhaustiva o completamente inequívoca, aplicar el principio de robustez maximiza las probabilidades de una interoperación fructífera entre los dos sistemas.
Por ejemplo:
En la especificación de un formato de fichero se indica que cada línea del fichero debe procesarse independientemente.
Esta especificación la implementan dos grupos por separado: un primer grupo que
trabaja en entornos UNIX (donde el separador de líneas es el byte 0x0A, o
\n) y otro grupo que trabaja en entornos Windows (donde el separador de
líneas es la secuencia de bytes 0x0D 0x0A, o \r\n).
Si la especificación del formato de fichero no indica explícitamente cuál es el separador de líneas, es razonable para los dos grupos asumir que cualquier de los dos tipos de separadores son válidos.
Ambos grupos, basándose en el principio de robustez, deberían aceptar ficheros que tengan cualqueira de los dos tipos de separador de líneas: de esa manera la implementación del grupo de Windows podrá recibir ficheros del grupo de UNIX y viceversa. Esta es la aplicación de la parte "ser flexbile en lo que aceptas" del principio.
Respecto a ser "conservador en lo que haces": ambos grupos deberían ser cuidadosos en no introducir saltos de líneas que tengan una finalidad cosmética para hacer más legible el fichero, si es que la especificación no indica explícitamente la corrección de dichos saltos. La introducción de esas líneas extra pueden ocasionar que el grupo que reciba el fichero las interprete no como elementos para mejorar la legibilidad, sino como datos reales.
Contras:
Flexibilizar la implementación de un protocolo para permitir la aparición de más elementos que los que indica la especificación... abre la puerta a la aparición de vulnerabilidades; de forma similar: al aceptar la necesidad de ser flexible se puede descuidar refinar la especificación.
Para minimizar la indefinición en la especificación de un protocolo es útil construir, a la vez que la especificación, una implementación de referencia. De esta manera experiencia en construir la implementación contribuye a la completitud de la especificación.