Кратко
- Verified означает, что сообщение рассмотрено и признано точным. Однако исправление не встраивается в обычные версии RFC в форматах TXT, PDF или XML.
- Эрраты относятся к ошибкам, существовавшим при публикации. Новые идеи, поздние возможности и изменение исходного консенсуса требуют возвращения в технический процесс.
Исправление остаётся рядом с документом
Команда находит противоречие в RFC. На странице эррат указаны исходный фрагмент, исправленный текст, дата и статус Verified. Следовать исправлению может быть необходимо для совместимости. Считать, что оно всегда находилось в RFC, значит удалить происхождение решения.
RFC фиксирует текст, прошедший рассмотрение, одобрение и публикацию в определённый момент. Эррата фиксирует более позднее и узкое суждение об ошибке. Первая запись показывает, что одобрило сообщество; вторая предупреждает о неверном результате буквального прочтения.
RFC Editor связывает слои, не скрывая шва. Проверенное исправление доступно читателю, но не попадает незаметно в обычные публикации. Так остаются различимыми первоначальное решение и последующий ремонт.
Это граница власти. Владение системой публикации само по себе не даёт права менять смысл протокола.
Четыре статуса совершают разные действия
Reported подтверждает только подачу заявления. Оно может быть правильным, ошибочным, неполным или слишком широким для этого канала. Автоматически применять его нельзя.
Verified означает, что сообщение действительно по применимым критериям и должно быть доступно разработчикам и операторам. Это сильнейший статус, но он исправляет ошибку в пределах исходного намерения, а не проектирует протокол заново.
Rejected означает, что просьба не проходит по этому пути. Иногда сообщение неверно; иногда изменение настолько существенно, что нужен новый RFC, обновляющий или заменяющий прежний.
Held for Document Update сохраняет вопрос, который не является необходимой правкой действующего RFC. Будущая редакция может его рассмотреть. Это не текущая обязанность и не предварительно одобренная норма.
Объединение четырёх статусов в поле «последний текст» уничтожает различие между заявлением, подтверждением, отказом и памятью для будущего.
Полномочие проверки следует за потоком
RFC Series включает потоки IETF, IAB, IRTF, Independent Submission и Editorial. У них разные цели и органы содержательного одобрения. Поэтому проверяющая сторона зависит от происхождения RFC.
Техническая эррата IETF-потока направляется авторам, председателям рабочей группы и Area Directors. Ответственность несут Area Directors, хотя рассмотрение можно делегировать. Явные редакционные ошибки сначала обрабатывает RFC Editor; вопросы технического смысла передаются компетентной стороне.
Так редакционная экспертиза отделяется от протокольной власти. Оператор базы не становится законодателем, а технический эксперт не меняет публичную память без следа решения.
Для аудита недостаточно слова Verified. Нужны поток, проверивший субъект, дата и мотивировка.
Исходное намерение задаёт предел
Действующее заявление IESG 2021 года ограничивает эрраты ошибками, присутствовавшими при публикации. Новые знания, появившиеся возможности и несогласие с одобренным результатом должны обсуждаться в рабочих группах, технических областях или IESG.
Ясное техническое решение, согласующееся с исходным намерением, можно признать Verified. Если требуется обсуждение, вопрос остаётся Held. Изменение работы протокола относительно консенсуса обычно следует отклонять. Нельзя также менять процедуру, например порядок регистрации IANA, если это изменяет прежнее решение.
Мало символов не значит мало власти. Нормативный глагол, значение по умолчанию или диапазон кодов способны изменить совместимость и распределение риска. Проверяющему нужны дискуссия группы, Last Call, позиции IESG, полный алгоритм и опыт реализаций.
Если материалы не доказывают единственное исправление, сохранить неопределённость честнее, чем создать уверенность без полномочия.
Переиздание файла не меняет его смысл
RFC 9720 разрешает контролируемое переиздание определяющей версии RFCXML и производных форматов из-за изменений схемы, ошибок XML или новых инструментов. Старые версии должны оставаться в архиве; дата и причина переиздания публикуются.
RFC 9920, вышедший в феврале 2026 года, заменил RFC 9280. Он сохраняет стабильность как историческое свойство серии и допускает переиздание ради согласованного представления. Центральное требование — сохранение исходной семантики.
Исправление обрезанного рисунка или неверного символа относится к сопровождению публикации. Подтверждение исходной ошибки относится к эррате. Изменение желаемого поведения требует нового нормативного решения.
Эта граница помогает расследованию: две системы следовали разным значениям или лишь читали разные отображения одного смысла?
Инженерная ссылка должна иметь версию и дату
Фразы «соответствует RFC 1234» недостаточно. Запись должна указывать использованную публикацию, обновляющие или отменяющие RFC, дату проверки эррат и принятые элементы Verified.
Тесты связывают исправление с наблюдаемым поведением. Если партнёры ещё следуют исходному тексту, примечания к выпуску объясняют совместимость. Ошибка безопасности может потребовать немедленной защиты при неизменном архиве.
Held влияет на будущий обзор, но не становится автоматическим несоответствием. Rejected показывает, что трактовка была рассмотрена и не получила статуса исправления.
Так архив не объявляется непогрешимым, а администратор эррат — законодателем. Рабочий набор ссылок развивается, сохраняя происхождение каждого слоя.
Тонкий общий реестр
Подход Heng Lu предпочитает узкое общее ядро, будущие решения компетентных участников и добровольное принятие, проверяемое работающими системами. Ограниченная система эррат соответствует этой конструкции.
Реестр способен назвать RFC, раздел, исходный и предложенный текст, тип, статус, проверяющего, дату и причину. Он не доказывает внедрение всеми поставщиками, обязательность Held или согласие из молчания закрытой группы.
Раздельность этих утверждений укрепляет легитимность. Эррата ценна точным описанием проверенной ошибки и предела суждения, а не обещанием, будто поздняя пометка стёрла историю.
Источники
- RFC Editor: Errata in RFCs
- RFC Editor: How to Verify RFC Errata
- IETF: RFCs — corrections and errata
- IESG Processing of RFC Errata for the IETF Stream
- RFC 9720: RFC Formats and Versions
- RFC 9920: RFC Editor Model (Version 3)
- The Bill of Rights of Uniqueness Coordination
- Running Code Primary
- Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
