Кратко

  • Final Review, прежде называвшийся AUTH48, начинается после одобрения Internet-Draft одним из публикационных потоков. Авторы проверяют полный текст, разметку и форматы, отвечают на вопросы и разрешают публикацию; это реальный контроль целостности, но не новое голосование IETF.
  • После попадания документа в очередь RFC Production Center управляет изменениями производственной копии. Редакционные исправления проходят в рамках этой опеки, а добавления, удаления, технические и иные выходящие за редактуру изменения требуют разрешения исходного потока.
  • Пилот kramdown-rfc и GitHub 2025–2026 годов сделал границу полномочий наблюдаемой. На 27 августа 2026 года у RFC-to-be 10025 были действующая страница Final Review и открытый репозиторий, но информационный адрес RFC 10025 ещё не содержал опубликованной записи.
  • Надёжная квитанция сохраняет одобренную редакцию draft, решение потока, набор правок RPC, классификацию вопросов, одобрения авторов и потока, хеши финальных файлов и публикационное объявление. Реализация и эксплуатация образуют отдельный слой доказательств.

Pull request, принятый за новое голосование

Снимок экрана не лгал. На нём были ветка RPC-edits, открытые issues, запрос на review и фамилии без последнего подтверждения. Ошибка возникла при свёртке: «публикационная копия ещё проверяется» превратилось в «содержание не одобрено», затем — в «авторы наложили вето» или «консенсус заново устанавливается на GitHub».

Final Review — промежуток хранения между двумя разными институциональными актами. До него один из потоков одобряет Internet-Draft к публикации. После него RPC выпускает определённый набор файлов и объявляет RFC. Между ними редакторы, авторы и представители потока проверяют верность производственной версии одобренному содержанию и готовность форматов стать долговременной записью.

Проверка не формальна. Потерянная строка алгоритма, сломанный фрагмент ABNF, неверная инструкция IANA или изменённое нормативное слово могут годами влиять на читателей. Но масштаб возможного вреда не расширяет юрисдикцию обнаружившего ошибку. RPC правит и задаёт вопрос; автор подтверждает верность; поток решает, допустим ли переход через редакционную границу.

В этом состоит governance-ценность открытой площадки. Она позволяет отличить одобренную исходную версию от правок RPC, вопрос от ответа, участие от полномочия. Прозрачность полезна, когда сохраняет роли, а не когда объявляет каждого видимого участника законодателем.

Одобрение происходит до очереди

Актуальное руководство по публикации RFC начинается до редакционного этапа. У потоков IETF, IAB, IRTF, Independent и Editorial свои пути одобрения. В RFC Production Center документ поступает только после решения соответствующего потока о публикации.

Этот акт задаёт содержательную основу и ответственную власть. В очереди RPC получает контроль изменений производственной копии. Автор не может незаметно заменить одобренный файл. Поправка проходит через RPC и, если она техническая или иным образом выходит за рамки редактуры, возвращается в исходный поток.

RFC 9920, действующая модель RFC Editor, прямо разделяет обязанности. Одобряющие органы отвечают за содержание своих потоков. Функция RFC Editor отвечает за производство и распространение. RPC редактирует, хранит историю правок и диалогов, выявляет потенциальный технический эффект, просит разъяснения, устанавливает готовность и публикует.

Это не спор между «настоящей техникой» и вспомогательной редактурой. Поток не сохранит надёжную серию, если одобрит идею и проигнорирует испорченные файлы. RPC не получает права проектировать протокол лишь потому, что держит производственную копию. Авторы тоже не возвращают себе единоличную собственность над коллективным решением.

Поэтому у проверяемого реестра сначала должны быть точный одобренный источник — редакция, байты и хеш — и одобривший поток. Без них последующие diff не имеют базы.

Что именно одобряют авторы

Авторская проверка не церемониальна. Авторы закрывают вопросы RPC, изучают изменения соавторов, читают полный текст, проверяют copyright и семантическую разметку, просматривают HTML, PDF и текст. Возможны несколько циклов обсуждения.

Инструкция пилота kramdown-rfc разделяет два подтверждения. Сначала авторы признают markdown достаточно стабильным для преобразования в RFCXML. Затем утверждают содержание и все финальные форматы. Разделение нужно потому, что верный исходник ещё может породить сломанный код, рисунок, ссылку или перенос.

Одобрение автора — это аттестация целостности. Она связывает имя человека с конкретными финальными материалами. Но она не ставит личное предпочтение выше решения рабочей группы, IESG или иного органа потока.

Правило для недоступного автора подтверждает замысел. Руководство разрешает переместить человека в Acknowledgements, в Contributors либо поручить менеджеру потока одобрить документ вместо него. Так признание вклада сохраняется, а недоступный почтовый ящик не превращается в вечное вето.

Отсутствующее подтверждение всё равно важно: только этот автор может заметить тонкое искажение. Следует записать попытки связи, выбранный путь замещения, лицо, разрешившее его, и причину. Вопрос должен решаться опубликованной процедурой, а не превращаться в неопределённую личную власть.

Граница, которую merge не пересекает

RPC запустил пилот kramdown-rfc 1 сентября 2025 года. Цели включали работу в знакомом авторам формате и более чистые diff, сосредоточенные на содержании. На старте планировалось принимать не менее пяти запросов в месяц и уточнять процесс по итогам практики.

К 2026 году публичные инструкции называли AUTH48 Final Review. Новое имя точнее: число 48 никогда не было гарантированным сроком. GitHub делает опеку наглядной: правки RPC живут в отдельной ветке, вопросы — в issues, предложения — в pull requests, разговор остаётся в архиве.

Репозиторий RFC-to-be 10025, новой редакции спецификации HTTP Cookie, служит текущим примером. README утверждает, что начальный markdown скопирован из Internet-Draft в виде, одобренном для публикации. Правки RPC отделены. Авторы утверждают содержание и форматы, Area Directors — выходящие за редактуру изменения; chairs и document shepherd также приглашаются, а при необходимости процесс возвращается к электронной почте.

27 августа 2026 года страница Final Review и репозиторий работали, тогда как информационный URL RFC 10025 отвечал 404. Интерфейс показывал пятнадцать issues и один pull request. Это не пятнадцать технических дефектов, не пятнадцать возражений и не пятнадцать заблокированных решений. Числа доказывают только наличие именованных рабочих пунктов.

Состояние изменится после снимка. Именно поэтому реестр хранит время наблюдения и авторитетные URL. Final Review — текущий статус. Опубликован как RFC 10025 станет отдельным событием лишь при появлении окончательной записи и объявления.

RFC 9991 и слово, потребовавшее решения AD

Реальная поправка лучше всего показывает границу. В ходе Final Review документа, ставшего RFC 9991, авторы предложили добавить ключевое слово BCP 14. Нормативные слова в верхнем регистре способны изменить техническое обязательство и не равны пунктуации.

В публичной переписке RPC попросил ответственного Area Director проверить и одобрить добавление. AD зафиксировал одобрение. Позже RPC выпустил RFC.

Смысл записи раскрывают глаголы. Авторы предложили. RPC распознал изменение, требующее иной власти, и запросил рассмотрение. AD одобрил. RPC опубликовал. Merge не заменил разрешение, а разрешение не выдавало публикацию за завершённую.

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

Почему 48 не было сроком

Название AUTH48 выглядело обещанием 48 часов. RFC 8963 исследовал выборку RFC, произведённых в 2018 году, отдельно учитывая редактирование, AUTH48 и интервал от окончательного согласия до выпуска. В выборке AUTH48 в среднем продолжался больше месяца и сильно варьировался.

RFC 8700 сохранил шутку о 48 днях или 48 неделях. Важнее институциональный вывод: технические изменения на этой стадии требуют разрешения соответствующего Area Director или менеджера потока.

Исторические цифры не делают каждую задержку провалом. Сложность, часовые пояса, недоступный автор, действие IANA, нормативная ссылка, Stream Hold и проблема инструмента имеют разных владельцев. Продолжительность задаёт вопрос, а не заранее отвечает, кто виноват.

Переименование убрало ложные часы. На их место не следует ставить столь же ложную урну. Стадия представляет собой контролируемое завершение.

Квитанция Final Review

Поле Сохраняемое доказательство Значение
Одобренный источник Имя draft, редакция, байты и хеш Фиксирует принятый потоком текст
Решение потока Поток, орган, дата и URL Называет публикационную власть
Передача RPC Время входа и состояние Отделяет решение от производственной опеки
Набор правок Ветка, diff или хеш Показывает изменения после одобрения
Пункты проверки Вопрос, участник, ответ и архив Приписывает неопределённость и её снятие
Класс изменения Редакционное, форматное, техническое или сверх редакционного Определяет необходимое разрешение
Одобрение авторов Лицо, охват и время Связывает людей с финальными файлами
Одобрение потока Квитанция AD или менеджера Не даёт опеке стать властью над содержанием
Внешние задержки IANA, ссылки, поток или инструменты Показывает настоящего владельца ожидания
Финальные материалы Хеши HTML, PDF, TXT и XML Связывает одобрение с выдаваемыми файлами
Публикация Объявление, URL и время Доказывает переход в RFC
Принятие Реализация, тесты и развёртывание Отделяет документ от работающей системы

Квитанция не превращает редакционное суждение в автомат. Она не позволяет ему потерять субъекта. Тогда можно точно сказать: не хватает проверки одного автора; техническая вставка ждёт AD; действие IANA не закончено; публикационной записи ещё нет. Такая формулировка менее эффектна, чем «вето» или «второе голосование», зато полезнее для внедрения и закупки.

Источники

Наблюдения о RFC-to-be 10025 относятся к 27 августа 2026 года. Число issues не трактуется как число дефектов; дата и исход публикации не прогнозируются.