Кратко

  • RFC 3930 сравнивала не текст RFC с работающим кодом, а воспринимаемый человеком целый объект с временным составным сообщением протокола.
  • Выбранная модель определяет обработку разных полей, совместимость расширений, канонизацию, область подписи и устойчивость внутренних идентификаторов после сборки.

Целое существовало только для наблюдателя

RFC 3930 намеренно утрирует позиции DOCUM и PROTO. Первая видит аналог листа бумаги вместе с оформлением, вторая — биты, созданные и потреблённые процессами с локальным контекстом. Карточка RFC Editor относит документ к Informational: это не стандарт и не перепись внедрений.

Одно поле могло возникнуть из предыдущего сообщения, другое — из локального вычисления, третье посредник лишь передавал дальше. RFC 3023 определяла типы XML, а RFC 3470 — рекомендации для XML в протоколах. Ни узнаваемый формат, ни разбор не доказывали переход состояния. RFC 3552 задавала дисциплину анализа угроз, RFC 3852 — криптографический контейнер; полномочия и результат оставались отдельными фактами.

Расширение встречало разные поколения

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

Проблема сохранилась в RFC 8259 для JSON, в RFC 8785 для канонического JSON и в RFC 8949 для детерминированного CBOR. Видимая ценность не равна единственному набору сравниваемых байтов.

Канонизация могла быть недостаточной и чрезмерной

RFC 3076, RFC 3741 и RFC 3275 задают фон XML. Слишком слабое преобразование ломает проверку из-за несущественных различий. Слишком широкое сохраняет подпись после значимой перемены. Полезна только граница эквивалентности приложения. Подписывать всё тоже неверно, если счётчик переходов, история маршрута или локальная метка должны меняться.

В самой RFC есть показательное расхождение. Раздел 2.4.1 ссылается на [RFC3741], что соответствует exclusive XML canonicalization, но список литературы раскрывает эту метку как документ GMPLS RFC 3471. Поиск errata не показывал исправления 7 октября 2026 года. Это не опровержение текста, а ограниченный пример того, что метку и реальный объект нужно сверять.

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

RFC 7990 позже описала архивную модель самой серии RFC — не автомат протокола. Тексты Heng Lu о минимальной исходной спецификации и добровольном принятии и приоритете работающего кода дают редакционную меру: публикация координирует, а реализация, проверка, эксплуатация и использование показывают, что стало реальностью.