Кратко

  • RFC 2234 оформил ABNF как отдельный документ после того, как спецификации Интернета включали собственные определения этой нотации.
  • Общий язык грамматик упрощает ссылки и объединение правил, но не доказывает, что разные реализации одинаково трактуют протокол.

Спецификация могла описывать устройство протокольных сообщений и одновременно объяснять нотацию, которой записаны эти правила. RFC 2234 приводит историческую причину: в первые годы ARPANET каждая спецификация содержала собственное определение ABNF. Документы по электронной почте RFC 733, а затем RFC 822 стали обычными источниками для такой ссылки. Но искать общее описание грамматического языка внутри документа конкретного протокола было неудобно.

Опубликованный в ноябре 1997 года RFC 2234 отделил это определение, чтобы другие спецификации могли ссылаться на него по мере необходимости. Это не означало, что Интернет перешёл на единый парсер. Документ дал общий ориентир для имён правил, терминалов, повторений, альтернатив, числовых диапазонов и группировки. ABNF описывает синтаксис допустимых строк, но не служит доказательством того, что принимает программа, работающая в сети.

Важно не смешивать уровни. ABNF описывает синтаксис; спецификация протокола выбирает правила для его сообщений; среда передачи определяет внешнее кодирование терминальных значений; парсер реализует эти решения. RFC 2234 отмечает, что одна грамматика может использоваться с разными внешними кодировками, и оставляет их детали за пределами ABNF. Поэтому нотацию можно было повторно применять в разных протоколах, не решая автоматически все вопросы о байтах на линии связи.

Правила можно собирать и по частям. Оператор =/ добавляет альтернативы к правилу, определённому в другом месте. RFC 2234 указывает, что это может быть полезно независимым спецификациям, основанным на общем наборе родительских правил. Это способ композиции документов, а не требование к парсерам автоматически искать расширения во время работы. Авторы по-прежнему должны назвать документы, которые вносят правила, и обозначить область их действия.

Так выглядит сдержанная техническая координация: общий словарь для записи правил, отдельные правила протоколов и явные решения о кодировании. RFC 2234 не устранил разногласия тем, что дал им названия, но сделал один слой этих разногласий более заметным. Последовательность обновлений — RFC 4234, затем RFC 5234 — показывает, что общий язык можно пересматривать. Позже RFC 7405 рассмотрел синтаксис, связанный с UTF-8; переносить эти изменения назад, в текст 1997 года, нельзя.

Это не история о том, как математика вытеснила прозу. Проза по-прежнему объясняет назначение и контекст протокола, а грамматика кратко описывает его форму. Полезное изменение состояло в том, что определение самого грамматического языка перестало обязательно находиться внутри каждой спецификации, которая его использует. Повторное использование получило чёткую ссылку, а утверждения о реализациях всё так же требуют доказательств на уровне самих реализаций.

Источники: RFC 2234; запись RFC 2234 в Datatracker; история RFC 2234 в Datatracker; запись RFC 2234 у RFC Editor; RFC 733; RFC 822; RFC 4234; запись RFC 4234 у RFC Editor; RFC 5234; запись RFC 5234 у RFC Editor; RFC 7405; RFC 2119; Лу Хэн о приоритете работающего кода; Лу Хэн о минимальной исходной спецификации; Лу Хэн об уровнях реальности.