Resumen

  • RFC 2234 convirtió ABNF en un documento independiente después de que las especificaciones de Internet incluyeran definiciones propias de la notación.
  • Compartir un lenguaje gramatical facilita citar y combinar reglas, pero no demuestra que distintas implementaciones interpreten igual cada protocolo.

Una especificación podía contar cómo se formaban los mensajes de un protocolo y explicar al mismo tiempo el sistema usado para escribir esas reglas. RFC 2234 describe la razón histórica: en los primeros tiempos de ARPANET, cada especificación contenía su propia definición de ABNF. Los documentos de correo RFC 733 y luego RFC 822 llegaron a ser referencias habituales. Aun así, una explicación general alojada dentro del documento de un protocolo concreto era un lugar poco práctico para consultar el lenguaje de las gramáticas.

Publicado en noviembre de 1997, RFC 2234 separó esa definición para que otras especificaciones pudieran citarla cuando les hiciera falta. El cambio no significaba que Internet adoptara un único analizador. Ofrecía una referencia común para nombres de reglas, terminales, repetición, alternativas, rangos numéricos y agrupación. ABNF expresa una sintaxis aceptable; no demuestra qué acepta un programa instalado en una red.

La diferencia entre capas es esencial. ABNF describe la sintaxis; cada documento de protocolo decide qué reglas definen sus mensajes; el entorno de transmisión determina cómo se codifican los valores terminales; y un analizador implementa esas decisiones. RFC 2234 señala que una misma gramática puede corresponder a distintos códigos externos y deja esos códigos fuera del alcance de ABNF. Por eso, la notación podía reutilizarse en varios protocolos sin resolver por sí sola todas las preguntas sobre los bytes que realmente cruzan una conexión.

La gramática también podía componerse por partes. El operador =/ añade alternativas a una regla definida en otro lugar; RFC 2234 dice que esto puede servir a especificaciones independientes que parten de un conjunto común de reglas. Es una facilidad para componer documentos, no una instrucción para que los analizadores descubran extensiones automáticamente. Los autores aún deben precisar qué documentos aportan reglas y cuál es su alcance.

Esa es una forma modesta de coordinación de Internet: normalizar el vocabulario con que se escriben reglas, mantener aparte las reglas propias de cada protocolo y hacer visibles las decisiones de codificación. RFC 2234 no eliminó los desacuerdos al ponerles nombre; hizo más fácil señalar una capa concreta de ellos. Su linaje —RFC 4234 y después RFC 5234— también muestra que un lenguaje compartido puede revisarse. RFC 7405 abordó más tarde la sintaxis relacionada con UTF-8; esas revisiones no deben proyectarse sobre el texto de 1997.

Esta historia no trata de reemplazar prosa por matemáticas. La prosa sigue explicando el propósito y el contexto de un protocolo; la gramática ofrece una descripción compacta de su forma. El movimiento útil consistió en alojar la definición del lenguaje gramatical fuera de cada protocolo que lo utilizaba. Así, la reutilización podía citarse, mientras que las afirmaciones sobre implementaciones seguían requiriendo evidencia de las propias implementaciones.

Fuentes: RFC 2234; registro Datatracker de RFC 2234; historial Datatracker de RFC 2234; registro RFC Editor de RFC 2234; RFC 733; RFC 822; RFC 4234; registro RFC Editor de RFC 4234; RFC 5234; registro RFC Editor de RFC 5234; RFC 7405; RFC 2119; nota sobre primacía del código en funcionamiento; nota sobre especificación inicial mínima; nota sobre capas de realidad.