- El bicicleta se me ha rrrroto
- Te puedo prestar la mía
- ¿"La mía"? ¿Bicicleta es un sustantivo femenino?
- Estooooo... sí
- ¡¡Y porrr qué no me lo has corrrregido??
- Bueno, te he entendido, no me pareció una cosa tan importante
- Sí lo essss. Te tengo dicho que no me pases ni uno
- De acuerdo. Se dice que "no me pases ni una"
- Grrrasssias
- Se dice "gracias"
- ¡Grrrmmppfff!
Sin saberlo, esta chica estaba aplicando en el ámbito de la filología una versión particular de la "Ley de Postel".
El Principio de Robustez
Jon Postel (Juanito para los amiguetes) fue un informático estadounidense, de los de la vieja escuela (nació en 1943 el buen hombre), que hizo muchas aportaciones a las tecnologías de Internet durante el nacimiento y los primeros años de la Red. Por algo lo llegaron a llamar "El Dios de Internet". Así, como suena, os lo aseguro. La verdad es que si vemos su foto, sí que se parece un poco a esa imagen un poco ñoña de dios como un viejecito con cara de buena persona con barba blanca (un amigo mío dice que le recuerda a David el Gnomo).
Fuente: Wikipedia, por el usuario Tedder
http://en.wikipedia.org/wiki/Jon_Postel#mediaviewer/File:Jon_Postel_sitting_in_office.jpg
Entre otras cosas, Postel fue el editor de numerosos documentos técnicos relacionados con estándares. Ya sabéis que los informáticos nos ponemos cachondos con las siglas, así que a estos documentos los llamaron RFC (Request For Comments). En concreto, el RFC 760 (si eres masoca, abajo tienes el enlace, aunque ya te aviso de que quedó obsoleto por documentos posteriores), especificaba lo relativo al protocolo TCP/IP, ya sabéis, una minucia sin importancia (con decir que prácticamente TODAS las comunicaciones en Internet se basan en él, ¡ahí es ná!). En ese RFC, Postel enunció, allá por enero de 1980, una frase famosa que pasó a la historia con su nombre. La "Ley de Postel" (o Principio de Robustez, que también se le llama así) viene a decir que "una implementación debería ser conservadora en lo que envía, y liberal al procesar lo que recibe" (traducción libre mía). También se ha enunciado a veces como "Sé liberal con lo que aceptas, sé conservador con lo que envías". Después de decir esta frase, Juanito se sentó con las manos cruzadas en su regazo, como lo véis en la foto.
En realidad, he mirado en el RFC 760 y este es el texto exacto del original en inglés (así podéis haceros vuestra propia traducción):
3.2. Discussion
The implementation of a protocol must be robust. Each implementation
must expect to interoperate with others created by different
individuals. While the goal of this specification is to be explicit
about the protocol there is the possibility of differing
interpretations. In general, an implementation should be conservative
in its sending behavior, and liberal in its receiving behavior. That
is, it should be careful to send well-formed datagrams, but should
accept any datagram that it can interpret (e.g., not object to
technical errors where the meaning is still clear).
De acuerdo, pero... ¿qué significa esto? Pues básicamente, que cuando uno produzca datos de salida que vayan a ser procesados por otros, intentar que estos datos se ajusten al máximo a las normas, que se sea todo lo estricto posible. Pero, por el contrario, a la hora de recibir y procesar datos de entrada, aceptar estos aunque presenten algún defecto menor que no afecte a la posible interpretación (es decir, que no se descarten unos datos por un defecto "de forma", como se anulaban antes algunas multas). O dicho más llanamente, sé muy quisquilloso con lo que produces, y sé muy permisivo con lo que producen los demás.
O como dice mi amiga la Jenny, "me lo trago tó".
Un ejemplo
Por ejemplo, si estoy esperando un color en formato hexadecimal para el fondo de una página web, y el diseñador ha escrito algo como
bgcolor=#AABBCC
pues su intención está clara. Quiere pintar el fondo de la página de ese color tirando a grisáceo (desde luego, hijo, qué soso). Sin embargo, para cumplir con la especificación oficial, el color debería estar entrecomillado, ya sea con comillas simples o dobles, así
bgcolor='#AABBCC'
Un programa que se encuentre el color como en el primer caso, sin las comillas, puede hacer varias cosas. Una de ellas (si fuera quisquilloso con lo que recibe, que es LO CONTRARIO de lo que recomienda Postel) es dar un mensaje diciendo que la página no es correcta, informar de ello y no mostrar la página. Vaya, qué programa tan exigente, ¿verdad?
Un programa más "enrollao", al leer la primera línea, entiende lo que se quiere decir, aunque falten las comillas. Si aplica la ley de Postel, ese programa debería interpretar el color como si el usuario hubiera introducido bien los datos, con el color entrecomillado. Como dice Postel, "...no poner objeciones a errores técnicos si el significado está claro". O sea, vale, no me has puesto las comillas en el color, pero entiendo lo que quieres decir. Pelillos a la mar. Esto sería un ejemplo del "be liberal".
Por otro lado, si ese mismo programa se encarga de generar o enviar datos, debe obligarse a sí mismo a cumplir estrictamente con el estándar, y enviar el código del color con las comillas correspondientes, incluso en el hipotético caso de que supiera que el receptor es capaz de "digerir" los datos sin comillas. Eso no valdría como excusa. Aquí quien manda es la especificación, y nunca se sabe si en una próxima actualización del programa receptor el programador encargado de la misma va a seguir manteniendo el criterio del primer equipo de desarrollo o va a reprogramar la parte encargada de procesar los colores, y entonces puede que algo que haya estando funcionando hasta el momento, de pronto deje de funcionar. Por ello, más vale forzarse uno a generar datos "buenos". Nivel de autoexigencia alto. No nos vamos a detener por unas comillas, ¿verdad? ¿Qué somos, leones o huevones?
Algunos de los mejores ejemplos de programas conservadores-liberales en este sentido lo tenemos en los navegadores más famosos. La mayoría de ellos son capaces de leer una página HTML y, aunque no esté bien formada, puede visualizarla haciendo algunas suposiciones razonables cuando se encuentre errores menores. Hay que tener cuidado, ya que puede que nos navegadores diferentes hagan diferentes suposiciones "razonables" (este concepto a veces es taaaaaan ambiguo...). De hecho, quizás os haya pasado a veces que hayáis comprobado que una página web se visualiza de forma ligeramente distinta en un navegador u otro, ¿verdad? Diferentes mentes, diferentes suposiciones "razonables".
También hay quien advierte de que una aplicación demasiado "tragona" puede poner en riesgo la seguridad precisamente por ese afán por aceptar datos que no sigan los patrones exactos que se esperan de ellos. Algo que también hay que tener en cuenta.
En fin, como resumen, que la ley de Postel viene a ser como una ley del embudo, pero al revés: lo ancho para los demás, lo estrecho para mis programas.
Un aparte
Además, la Ley de Postel es una buena receta para otras facetas de la vida. ¿Os imagináis cómo funcionaría la Sociedad, por ejemplo, si todos fuéramos un poco más transigentes con lo que esperamos de los demás, y fuéramos más estrictos con lo que le damos nosotros al mundo? Normalmente, solemos funcionar al revés.
La estudiante de la que os hablaba al principio es otro buen ejemplo de la parte "be conservative": se exigía hablar perfectamente bien, aunque sabía que podía defenderse y hacerse entender con soltura hablando regular. Pero no, ella tenía un nivel alto de autoexigencia. Be conservative.
Bueno, todo esto lo decía como introducción para hablar sobre el tema de la validación de documentos HTML, pero como esta entrada me está quedando ya un poco larga, hablaré de ello en otra ocasión.
Que ustedes lo codifiquen bien (y conservadoramente ;-)
Y rezadle a Postel.
Referencias
El principio de Robustez, explicado un poco más en detalle
En inglés: http://en.wikipedia.org/wiki/Robustness_principle
El RFC 760, donde se enunció por primera vez este principio
http://tools.ietf.org/html/rfc760
