Si no te dedicas a esto de las tecnologías de la información y la comunicación o te trae al pairo el funcionamiento y de la internet ya puedes salir pitando de aquí porque no voy a escatimar en referencias para describir y contextualizar las llamadas Request For Comments, más conocidas por sus iniciales, RFC; que puede decirse que son la biblia de internet y de las que debo confesar que nunca he sabido muy bien cómo se guisan y en qué cocina se preparan.

Una definición inicial, ¿qué son las RFC?

Básicamente las RFC son documentos de especificación muy detallada y sin ambigüedades de protocolos, procedimientos y/o eventos definidos para la internet. Cada RFC tiene un número asignado, que no puede repetirse ni eliminarse aunque el documento quede obsoleto; cuanto mayor sea este número, más actualizada será la versión.

Pero empecemos por el principio

Resulta que la primera RFC tiene fecha del 7 de abril de 1969 y fue creada por Steve Crocker (foto a la derecha), por aquel entonces estudiante de postgrado en UCLA y líder de un grupo de investigación¹ que quería intercomunicar los cuatro primeros nodos de una red de ordenadores entre UCLA (Universidad de California, Los Ángeles), UCSB (Universidad de California, Santa Bárbara), SRI (Stanford Research Institute) y la Universidad de Utah. Estamos hablando de la primigenia ARPANET. Crocker tomó la iniciativa de organizar las notas que el grupo fue generando desde sus inicios para documentar el trabajo realizado. Según explicaba el propio Steve:

La mayoría de nosotros éramos estudiantes de postgrado y esperábamos que en cualquier momento vendría un grupo de profesionales para hacerse cargo y resolver los problemas que estábamos tratando.²

Más o menos creían que aquellos trabajos algún día pasarían a ser liderados por otras personas, pero no fue así y al final Crocker se admiraba de que:

… cualquiera podía decir lo que quisiera y que nada sería oficial. Para dejar esto muy claro denominé las notas como ‘Solicitud de Comentarios’ (Request for Comments, RFC). Jamás soñé que esas notas serían distribuidas a través del mismo medio del que hablábamos en ellas.²

A comienzos de 1970 sería un alumno amigo de Crocker llamado Jon Postel (foto a la izquierda), y a la postre otro de los padres de internet³, quien se encargaría de recopilar, copiar, distribuir y archivar todas las RFC desde el que llamarían Centro de Información de la Red, Network Information Center ó NIC⁴, en el SRI, convirtiéndose en el editor oficial de RFC‘s durante veinticinco años y el autor más prolífico ya que escribió o participó en más de 200 RFC‘s, algunas de ellas claves para la actual internet como los protocolos IP (RFC 791), ICMP (RFC 792) y TCP (RFC 793); o definiendo las instrucciones para otros autores de RFC‘s (RFC 2223).

El caso es que estos documentos empezaron como un mecanismo informal para compartir ideas con otros investigadores de tal manera que las propuestas presentadas en una RFC impulsaran otra RFC con nuevas ideas y así sucesivamente hasta llegar por consenso a una especificación definitiva para su implementación. Ahora nos sorprende, pero resulta evidente que al principio las RFC, redactadas en texto plano ASCII, tenían que imprimirse y distribuirse por correo ordinario. En el momento que empezó a usarse el protocolo FTP para la transferencia de ficheros fue cuando las RFC comenzaron a difundirse a través de la red.

Y así han llegado a convertirse en los únicos documentos oficiales dentro de la comunidad de estándares en Internet, aunque ningún funcionario ni organismo les ha dado jamás el visto bueno para ser tal cosa.

¿Y en la actualidad qué pasa con las RFC?

Pues ahora las RFC son publicadas, adoptadas y reguladas como estándares de internet por IETF (Internet Engineering Task Force⁵, algo así como Grupo Especial sobre Ingeniería de Internet), organización internacional sin ánimo de lucro creada en 1986 –celebró su 25 aniversarion en enero– y conocida por su carácter abierto ya que cualquier persona puede ser miembro a título personal. Se estructura en grupos de trabajo con técnicos en redes, investigadores, diseñadores de red, administradores, vendedores y profesionales que velan por el buen funcionamiento de la arquitectura de Internet y los protocolos que la conforman.

Por tanto, cualquiera puede contribuir con nuevas RFC a la IETF siempre que se cumplan las reglas expuestas en RFC 5378 y RFC 3979 (actualizada por RFC 4879). Todas las RFC, incluyendo las que describen estándares de internet, son propiedad de ISOC⁶, acrónimo de Internet Society, aunque están disponibles libremente y sin coste para todo el mundo.

Actualmente el sitio oficial para buscar cualquier RFC es http://www.rfc-editor.org⁷, cuyo diseño parece no haber cambiado desde su versión para Mosaic.

Buenas prácticas y otros tipos de RFC’s

Las RFC de buenas prácticas, o Best Current Practices, son un subconjunto importante entre todas las RFC, hasta el punto de que tienen su propia numeración interna, BCPXXX donde XXX es un número secuencial que no se repite.

Por ejemplo, en la RFC 2026, de octubre de 1996, actualizada por la relativamente reciente RFC 5657, de septiembre de 2009, y agrupadas ambas por el identificador BCP9, se detallan un conjunto de buenas prácticas para la estandarización de protocolos y procedimientos, incluyendo una serie de estados para indicar el grado de madurez de una RFC, que para las que serán estándares de internet son:

• «PROPOSED STANDARD», ó «PROPUESTA«; estado de las RFC que están siendo consideradas para ser un futuro estandar.
• «DRAFT STANDARD», ó «BORRADOR«; en este estado se está considerando seriamente adoptar el estándar y sólo se modificarán aspectos que solucionen defectos del estándar propuesto.
• «INTERNET STANDARD», ó «ESTÁNDAR«; aquellas RFC que oficialmente se convierten en estándar de internet. Se podría hablar de dos categorías, aquellas que se aplicarán a toda la internet y las que sólo afectan a ciertas redes.

Las RFC de estándares tienen también su propia numeración interna, STDXXX donde XXX es el correspondiente secuencial que no se repite. El STD1 contiene la lista actual completa de los protocolos oficiales de internet, que ahora se corresponde con la RFC 5000, de mayo de 2008, que dejó obsoleta la 3700, que a su vez dejó obsoleta la 3600 hasta la 1083 que incluyó el primer listado oficial de protocolos.

Las categorías para las RFC que no definen estándares de la internet son:

• «EXPERIMENTAL»; aquellas usadas para pruebas de investigación.
• «INFORMATIONAL», ó «INFORMATIVA«; con información general para la comunidad. Algunas incluso se han preparado fuera de la comunidad y no se incorporan al proceso de normalización. Algunas RFC en esta categoría son simplemente bromas (ver más abajo).
• «HISTORIC», ó «HISTÓRICA«; son las que han sido reemplazadas por versiones más nuevas y han quedado obsoletas. También pueden ser aquellas que no han recibido suficiente apoyo o han tenido poco interés.

Hay un tercer subconjunto entre las RFC que se nombran como FYIXXX, ya sabes, XXX es un secuencial; que son documentos creados For Your Information, más exactamente vienen a ser RFC‘s que destacan por su especial interés para los usuarios de internet. Estas RFC deben tener el estado «INFORMATIONAL». Por ejemplo, FYI20 es la RFC 1462 donde se explica nada menos qué es internet.

¿Algún detalle más de las RFC?

Pues en la RFC 2119, de marzo del 97, se describen una serie de palabras clave que suelen aparecer en mayúsculas al principio de muchas RFC para indicar ciertos niveles en la aplicación de los requerimientos del documento:

• «MUST» («DEBE«), esta palabra, o los términos «REQUIRED» («OBLIGATORIO«) o «SHALL» («DEBERÁ«) indicarán que un requerimiento de la especificación es absolutamente imprescindible.
• «MUST NOT» («NO DEBE«), o la frase «SHALL NOT» («NO DEBERÁ«) indicarán una prohibición absoluta en la especificación.
• «SHOULD» («DEBERÍA«), o «RECOMMENDED» («RECOMENDADO«) significan que en determinadas circunstancias y conociendo las implicaciones, se pueden ignorar parte de las especificaciones.
• «SHOULD NOT» («NO DEBERÍA«), o la frase «NOT RECOMMENDED» («NO RECOMENDADO«) indicarán que en determinadas circunstancias y conociendo las implicaciones, puede ser útil aplicar ciertas especificaciones aunque no deba hacerse.
• «MAY» («PUEDE«), o la palabra «OPTIONAL» («OPCIONAL«) indicará un elemento que podrá aplicarse opcionalmente a elección del proveedor, por ejemplo porque sienta que un mercado en particular lo necesite o porque crea que mejora el producto.

Estos términos se usan normalmente en especificaciones con implicaciones de seguridad, y recomiendan ser usados con cuidado y mesura; por ejemplo no deberían utilizarse para intentar imponer un método concreto a los implementadores a no ser que la interoperabilidad (palabra que comercialmente está ahora muy de moda) lo requiera.

Sentido del humor de los científicos de la red

Algunas RFC son simple y llanamente bromas, inocentadas o memorándums jocosos que se añaden a la biblioteca de RFC’s por puro entretenimiento. A mí me ha hecho especial gracia la RFC 3751, de abril de 2004, editada por Scott Bradner de la Universidad de Harvard, que analiza los requerimientos para un ¡¿protocolo omnisciente?! capaz de resolver las carencias que actualmente tiene la red para interferir activamente en las actividades que puedan catalogarse como ilegales de los usuarios de la red.

Fuentes y referencias

Bueno, pues ahora ya sé kung fu, perdón, ya sé bastante sobre RFC‘s como para darme por satisfecho. Pero si quieres profundizar más puedes empezar por donde yo:

• http://www.livinginternet.com/i/ia_rfc.htm
• http://en.wikipedia.org/wiki/Request_for_Comments
• http://www.eumed.net/cursecon/ecoinet/conceptos/Crocker.htm
• http://www.isoc.org/isoc/
• http://TIC-tac.teleco.uvigo.es/profiles/blogs/introduccion-a-request-for
• http://www.ati.es/DOCS/internet/histint/

Notas al contenido

1. Aquel Grupo de Trabajo en Redes, el Network Working Group, nunca llegó a constituirse formalmente pero desde las primeras reuniones entre Steve Crocker, Steve Carr (también de UCLA) y Jeff Rulifson (de la Universidad de Utah), se autodenominaron así y como tal aparece en las cabeceras de las RFC.
2. Comentarios extraídos de una guía de referencia de las Request For Comments publicada en el RFC 1000 (agosto de 1987). También en abril de 1999 se publicó el RFC 2555 dedicada a repasar los 30 años de RFC‘s hasta la fecha.
3. Jon Postel llegaría a ser uno de los hombres más poderosos de la red al encargarse de la administración mundial del DNS y siendo durante casi 30 años director de IANA, la antigua agencia encargada de administrar las direcciones IP en la red antes de ser sustituida por ICANN en 1998.
4. Que luego pasaría a ser el Centro de Información de la Red Internet, Internet Network Information Center ó InterNIC que seguramente también te sonará como responsable de los nombres de dominio y direcciones IP porque fue la antesala de IANA.
5. En la RFC 3160 se recopila una guía muy completa y útil para los principiantes que se incorporan a la IETF.
6. ISOC se creó en 1992 como una sociedad internacional dedicada al desarrollo mundial de Internet en asuntos como estádares, educación y políticas de la red. IETF pasó a depender de ISOC recibiendo cobertura legal además de económica con aportaciones de alrededor de un millón de dólares anuales para la elaboración de las RFC.
7. En http://www.rfc-editor.org/rfc-index2.HTML tienes un listado completo de todas las RFC.