Request for Comments
| ||||
RFC son las siglas del término en inglés de Request for Comments (Solicitud de comentarios) referido a la Serie de notas sobre Internet que comenzaron a publicarse en 1969. Cada una de ellas individualmente es un documento cuyo contenido es una propuesta oficial para un nuevo protocolo de la red Internet (originalmente de ARPANET), que se explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambigüedades.
Sumario
Historia
La creación del formato RFC se produjo en 1969 como parte del proyecto ARPANET. Hoy en día, es el canal de la publicación oficial de la IETF (Internet Engineering Task Force), el Internet Architecture Board (IAB), y -en algunos medida- la comunidad global de investigadores de la red informática en general.
Los autores de las RFC primeras, mecanografiaron sus trabajos y distribuyeron copias entre los investigadores de ARPA. A diferencia de las RFCs modernas, muchos de las primeras RFCs fueron las solicitudes de comentarios. La RFC deja preguntas abiertas y está escrita en un estilo menos formal. Este estilo menos formal, caracteriza a los proyectos de documentos de Internet, el paso precursor antes de ser aprobado como una RFC.
En diciembre de 1969, los investigadores comenzaron a distribuir RFC nuevas a través de la nueva ARPANET operativa. RFC 1 titulado "Host Software", fue escrito por Steve Crocker de la Universidad de California en Los Ángeles (UCLA), y publicado el 7 de abril de 1969. Aunque escrito por Steve Crocker, el RFC surgió de una discusión de grupo a principios de trabajo entre Steve Crocker, Carr Steve y Jeff Rulifson. (El documento enumera Bill Duvall como presente sólo la última reunión del grupo de trabajo antes de su publicación.)
En el RFC 3 que definió por primera vez la serie de RFC, Crocker comenzó atribuir la serie RFC al "Grupo de Trabajo de la Red". Este grupo parece que nunca han tenido una existencia formal, en lugar de ser definido como "este grupo de personas", pero la atribución sigue siendo el RFC para el día de hoy.
Muchos de las RFCs posteriores de la década de 1970 también vinieron de la UCLA, no sólo por la calidad de la beca, sino también por la UCLA fue uno de los primeros procesadores de interfaz de mensajes (PIM) en la ARPANET.
Características
Cada RFC tiene un título y un número asignado, que no puede repetirse ni eliminarse aunque el documento se quede obsoleto. Existen varias categorías, pudiendo ser informativos (cuando se trata simplemente de valorar por ejemplo la implantación de un protocolo), propuestas de estándares nuevos, o históricos (cuando quedan obsoletos por versiones más modernas del protocolo que describen).
Las RFC se redactan en inglés según una estructura específica y en formato de texto ASCII.
Antes de que un documento tenga la consideración de RFC, debe seguir un proceso muy estricto para asegurar su calidad y coherencia. Cuando lo consigue, prácticamente ya es un protocolo formal al que probablemente se interpondrán pocas objeciones, por lo que el sentido de su nombre como petición de comentarios ha quedado prácticamente obsoleto, dado que las críticas y sugerencias se producen en las fases anteriores. De todos modos, el nombre de RFC se mantiene por razones históricas.
Obtención de RFC
La fuente oficial para el RFC en la World Wide Web es el RFC Editor.
Se puede obtener casi cualquier RFC publicado, como por ejemplo RFC 5000, a través de una URL en la forma del siguiente ejemplo: http://www.rfc-editor.org/rfc/rfc5000.txt
Cada RFC se presenta como texto plano ASCII y se publica en esa forma, pero también pueden estar disponibles en otros formatos. Sin embargo, a partir de 2008 la versión definitiva de cualquier pista estándar es la versión ASCII.
Para facilitar el acceso a los metadatos de un RFC, incluyendo resumen, palabras clave, autor (s), fecha de publicación, erratas, estado y sobre todo últimas actualizaciones , el sitio RFC Editor ofrece un buscador con muchas características. Una redirección establece algunos parámetros de eficiencia, por ejemplo: http://purl.net/net/rfc/5000
Estado
No todas las RFC son normas. Cada RFC se le asigna una denominación con respecto al estado en el proceso de estandarización de Internet. Este estado es uno de los siguientes: Informativo, Experimental, Mejor Práctica Actual (BCP), Pistas Estandar , o Históricos. Los documentos de Pistas Estandar se dividen en de Norma propuesta, Proyecto de Norma, y en Documentos Estándar de Internet. El término histórico se aplica a los documentos obsoletos estándares o RFC obsoletos que se publicaron antes que la pista de las normas se estableció. Sólo la IETF, representada por la Internet Engineering Steering Group (IESG), puede aprobar normas RFC. Cada RFC es estática, si el documento se cambia, se confirma de nuevo y se le asigna un nuevo número de RFC. Si un RFC se convierte en un estándar de Internet (STD), se le asigna un número STD, pero conserva su número de RFC, sin embargo, cuando una norma de Internet se pone al día, su número sigue siendo el mismo y simplemente se refiere a otro RFC o conjunto de RFC. Un determinado estándar de Internet, STD n, puede ser RFC x ó y en un momento dado, pero más tarde la misma norma puede ser actualizado para ser compatible con RFC z en su lugar. Por ejemplo, en 2007 RFC 3700 fue un estándar de Internet-STD 1- y en mayo de 2008 fue reemplazado por RFC 5000, por eso RFC 3700 cambió a histórico, RFC 5000 se convirtió en un estándar de Internet, ya partir de mayo de 2008 STD 1 es el RFC 5000. Cuando un STD se actualiza de nuevo, simplemente se refieren a un RFC reciente que se haya completado la pista de norma, pero seguirá siendo un STD. Las Mejores Prácticas Actuales funcionan de una manera similar; BCP n se refiere a una cierta RFC o conjunto de RFC, pero que el RFC o RFCs pueden cambiar con el tiempo.
La lista definitiva de Estándares de Internet en sí es un estándar de Internet, STD 1: Protocolo de Normas Oficiales de Internet.
Estado "informativo"
Un RFC informativo puede ser casi cualquier cosa, desde los chistes sobre protocolos propietarios hasta ampliamente reconocidos RFCs esenciales como Estructura y delegación del sistema de nombres de dominio (RFC 1591). Algunos RFCs informativos forman la subserie para la información (FYI). Si bien rara vez se agregan el día de hoy, algunos FYI antiguos todavía son interesantes, por ejemplo, FYI 18 (RFC 1983), Glosario del usuario de Internet. FYI 17, El Tao de la IETF, es ahora el RFC 4677, publicado en 2006.
Estado "experimental"
Un RFC experimental puede ser un documento IETF o presentación individual a la RFC Editor. En teoría sí es experimental, en la práctica algunos documentos no se promueven en las normas de la pista porque no hay voluntarios para conocer los detalles de procedimiento.
Estado "mejor práctica actual"
La subserie de mejores prácticas actuales (BCP) recoge los documentos administrativos y otros textos que se consideran como las reglas oficiales y no sólo de información, pero las cuales no afectan los datos del cable. La frontera entre la pista estándar y BCP a menudo no está clara. Si un documento sólo afecta al proceso de normalización de Internet, como BCP 9, o la administración del IETF, que es claramente un BCP. Si sólo define las reglas y regulaciones para la Internet Assigned Numbers Authority (IANA) registrar esto no está tan claro; la mayoría de estos documentos son los PCB, pero algunos están en las pistas estándar.
Estado "histórico"
Un RFC histórico es el que ha quedado obsoleto por una nueva versión, los documentos de un protocolo que no se considera interesante en la actual Internet, o ha sido retirado de la pista estándar por otras razones. Algunos RFCs obsoletos no están clasificados como históricos, ya que el proceso de normas de Internet en general, no permite las referencias normativas a partir de una pista estándar RFC a otra con menor estatus. Además, son pocos los interesados en trabajar a través de los detalles de procedimiento necesario para obtener un RFC clasificado como histórico y actualizar todos los RFC normativamente en función de ello.
Estado "desconocido"
Estado desconocido se utiliza para algunos RFCs muy antiguos, donde no está claro que estado del documento se obtendría si se publica hoy. Algunos de estos RFCs no serían publicados del todo hoy; uno de los primeros RFCs a menudo era precisamente eso: una simple solicitud de comentarios, que no quería concretar un protocolo, el procedimiento administrativo, o cualquier otra cosa para la que se utiliza la serie de RFC hoy.
